Re: [PATCH v4 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Memory allocated for the hypervisor heap is not accounted to the memcg of the container creating the VM, creating a memory limit bypass. Prior to this patch, `hyp_vm` was allocated on the host using `GFP_KERNEL_ACCOUNT`, correctly attributing the memory to the calling process's memcg. With the shift to EL2 dynamic allocation via `hyp_alloc()`, when the heap requires more memory, EL2 requests a top-up from the host via `PKVM_HYP_REQ_HYP_ALLOC`. The host handles this in `pkvm_hyp_topup()` by creating a temporary memcache and initializing it with `init_hyp_memcache(&mc)`. However, `init_hyp_memcache()` zeroes the memcache flags, meaning `HYP_MEMCACHE_ACCOUNT_KMEMCG` is not set. Consequently, when `topup_hyp_memcache()` allocates host pages, `hyp_mc_alloc_fn()` falls back to `GFP_KERNEL` instead of `GFP_KERNEL_ACCOUNT`. This hides the hypervisor heap allocations from memcg limits, allowing a container to exhaust host memory by creating VMs with maximum vCPUs without being charged.
--

--- Patch [13]: [PATCH v4 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator ---
commit 3a3fbdf527ba4d3c04e2e5d3272e58f6042e8822
Author: Vincent Donnefort <[email protected]>

KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator
    
This commit transitions the allocation of the hypervisor VM state structure
(pkvm_hyp_vm) to the pKVM heap allocator at EL2. The host now uses
pkvm_call_hyp_req() to invoke __pkvm_init_vm, handling any EL2 heap top-up
requests dynamically instead of donating pre-allocated host memory.

> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index bfbb1266491d1..a9b85ad37787a 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c

[ ... ]

> @@ -209,28 +209,15 @@ static int __pkvm_create_hyp_vm(struct kvm *kvm)
>  	if (!pgd)
>  		return -ENOMEM;
>  
> -	/* Allocate memory to donate to hyp for vm and vcpu pointers. */
> -	hyp_vm_sz = PAGE_ALIGN(size_add(PKVM_HYP_VM_SIZE,
> -					size_mul(sizeof(void *),
> -						 kvm->created_vcpus)));
> -	hyp_vm = alloc_pages_exact(hyp_vm_sz, GFP_KERNEL_ACCOUNT);
> -	if (!hyp_vm) {
> -		ret = -ENOMEM;
> -		goto free_pgd;
> -	}
> -
> -	/* Donate the VM memory to hyp and let hyp initialize it. */
> -	ret = kvm_call_hyp_nvhe(__pkvm_init_vm, kvm, hyp_vm, pgd);
> +	ret = pkvm_call_hyp_req(__pkvm_init_vm, kvm, pgd);

[Severity: High]
Does this new allocation path lose the memcg accounting for the hyp_vm
structure?

Previously, hyp_vm was allocated on the host using GFP_KERNEL_ACCOUNT, which
correctly attributed the memory to the calling process's memcg.

With the shift to EL2 dynamic allocation, when the heap requires more memory,
EL2 requests a top-up via PKVM_HYP_REQ_HYP_ALLOC. When the host handles this
in pkvm_hyp_topup(), it creates a temporary memcache using
init_hyp_memcache(), which leaves the HYP_MEMCACHE_ACCOUNT_KMEMCG flag
cleared.

Because of this, when topup_hyp_memcache() allocates host pages,
hyp_mc_alloc_fn() falls back to GFP_KERNEL instead of GFP_KERNEL_ACCOUNT.
This hides the hypervisor heap allocations from memcg limits.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=13