Re: [RFC 02/14] x86/apic: Initialize Secure AVIC APIC backing page

From: Neeraj Upadhyay
Date: Wed Oct 09 2024 - 12:36:56 EST




On 10/9/2024 8:57 PM, Dave Hansen wrote:
> On 9/13/24 04:36, Neeraj Upadhyay wrote:
>> + sz = ALIGN(num_possible_cpus() * SZ_4K, SZ_2M);
>> + backing_pages = kzalloc(sz, GFP_ATOMIC);
>> + if (!backing_pages)
>> + snp_abort();
>
> Is this in an atomic context? If not, why the GFP_ATOMIC?
>

No. I think GFP_ATOMIC is not required. I will change it to GFP_KERNEL.


> Second, this looks to be allocating a potentially large physically
> contiguous chunk of memory, then handing it out 4k at a time. The loop is:
>
> buf = alloc(NR_CPUS * PAGE_SIZE);
> for (i = 0; i < NR_CPUS; i++)
> foo[i] = buf + i * PAGE_SIZE;
>
> but could be:
>
> for (i = 0; i < NR_CPUS; i++)
> foo[i] = alloc(PAGE_SIZE);
>
> right?

Single contiguous allocation is done here to avoid TLB impact due to backing page
accesses (e.g. sending ipi requires writing to target CPU's backing page).
I can change it to allocation in chunks of size 2M instead of one big allocation.
Is that fine? Also, as described in commit message, reserving entire 2M chunk
for backing pages also prevents splitting of NPT entries into individual 4K entries.
This can happen if part of a 2M page is not allocated for backing pages by guest
and page state change (from private to shared) is done for that part.


- Neeraj