Messages in this thread | | | Subject | Re: [PATCH v5 5/5] x86/kvm: Avoid dynamic allocation of pvclock data when SEV is active | From | Brijesh Singh <> | Date | Thu, 6 Sep 2018 16:56:06 -0500 |
| |
On 09/06/2018 03:39 PM, Sean Christopherson wrote: > On Thu, Sep 06, 2018 at 03:20:46PM -0500, Brijesh Singh wrote: >> >> >> On 09/06/2018 02:47 PM, Sean Christopherson wrote: >> ... >> >>>> >>>> Yes, the auxiliary array will dumped into the regular .bss when >>>> CONFIG_AMD_MEM_ENCRYPT=n. Typically it will be few k, I am not >>>> sure if its worth complicating the code to save those extra memory. >>>> Most of the distro's have CONFIG_AMD_MEM_ENCRYPT=y anyways. >>> >>> I just realized that we'll try to create a bogus array if 'NR_CPUS <= >>> HVC_BOOT_ARRAY_SIZE'. A bit ugly, but we could #ifdef away both that >>> and CONFIG_AMD_MEM_ENCRYPT=n in a single shot, e.g.: >>> >>> #if defined(CONFIG_AMD_MEM_ENCRYPT) && NR_CPUS > HVC_BOOT_ARRAY_SIZE >>> #define HVC_AUX_ARRAY_SIZE \ >>> PAGE_ALIGN((NR_CPUS - HVC_BOOT_ARRAY_SIZE) * \ >>> sizeof(struct pvclock_vsyscall_time_info)) >>> static struct pvclock_vsyscall_time_info >>> hv_clock_aux[HVC_AUX_ARRAY_SIZE] __decrypted __aligned(PAGE_SIZE); >>> #endif >>> >> >> The HVC_BOOT_ARRAY_SIZE macro uses sizeof(..) and to my understanding >> the sizeof operators are not allowed in '#if'. Anyway, I will try to see >> if it can be used, if not then I will stick to CONFIG_AMD_MEM_ENCRYPT >> check. > > Hmm, we'll need something otherwise 'NR_CPUS - HVC_BOOT_ARRAY_SIZE' > will wrap and cause build errors. >
Right.
One option is we can hard-code the check for > 64, something like this:
#if defined(CONFIG_AMD_MEM_ENCRYPT) && NR_CPUS > 64 ... ... #endif
But this assumption will break if we ever add a new field in struct pvclock_vsyscall_time_info. Hence I am not in favor of this.
Second option is, use KVM_MAX_VCPUS or NR_CPUS, something like this:
#ifdef CONFIG_AMD_MEM_ENCRYPT #define HVC_AUX_ARRAY_SIZE \ PAGE_ALIGN(NR_CPUS * sizeof(struct pvclock_vsyscall_time_info)) ... #endif
In this case we will allocate few extra bytes which will get freed for the non-SEV case anyways.
| |