| Message ID | 20241212155610.76522-30-steven.price@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: Support for Arm CCA in KVM | expand |
On 12/13/24 1:55 AM, Steven Price wrote: > Always split up huge pages to avoid problems managing huge pages. There > are two issues currently: > > 1. The uABI for the VMM allows populating memory on 4k boundaries even > if the underlying allocator (e.g. hugetlbfs) is using a larger page > size. Using a memfd for private allocations will push this issue onto > the VMM as it will need to respect the granularity of the allocator. > > 2. The guest is able to request arbitrary ranges to be remapped as > shared. Again with a memfd approach it will be up to the VMM to deal > with the complexity and either overmap (need the huge mapping and add > an additional 'overlapping' shared mapping) or reject the request as > invalid due to the use of a huge page allocator. > > For now just break everything down to 4k pages in the RMM controlled > stage 2. > > Signed-off-by: Steven Price <steven.price@arm.com> > --- > arch/arm64/kvm/mmu.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index e88714903ce5..9ede143ccef1 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1603,6 +1603,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > if (logging_active) { > force_pte = true; > vma_shift = PAGE_SHIFT; > + } else if (kvm_is_realm(kvm)) { > + // Force PTE level mappings for realms > + force_pte = true; > + vma_shift = PAGE_SHIFT; > } else { > vma_shift = get_vma_page_shift(vma, hva); > } Since a memory abort is specific to a vCPU instead of a VM, so vcpu_is_rec() instead of kvm_is_realm() is more accurate for the check. Besides, it looks duplicate to the check added by "PATCH[20/43] arm64: RME: Runtime faulting of memory", which is as below. /* FIXME: We shouldn't need to disable this for realms */ if (vma_pagesize == PAGE_SIZE && !(force_pte || device || kvm_is_realm(kvm))) { ^^^^^^^^^^^^^^^^^ Can be dropped now. Thanks, Gavin
On 02/02/2025 06:52, Gavin Shan wrote: > On 12/13/24 1:55 AM, Steven Price wrote: >> Always split up huge pages to avoid problems managing huge pages. There >> are two issues currently: >> >> 1. The uABI for the VMM allows populating memory on 4k boundaries even >> if the underlying allocator (e.g. hugetlbfs) is using a larger page >> size. Using a memfd for private allocations will push this issue onto >> the VMM as it will need to respect the granularity of the allocator. >> >> 2. The guest is able to request arbitrary ranges to be remapped as >> shared. Again with a memfd approach it will be up to the VMM to deal >> with the complexity and either overmap (need the huge mapping and add >> an additional 'overlapping' shared mapping) or reject the request as >> invalid due to the use of a huge page allocator. >> >> For now just break everything down to 4k pages in the RMM controlled >> stage 2. >> >> Signed-off-by: Steven Price <steven.price@arm.com> >> --- >> arch/arm64/kvm/mmu.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c >> index e88714903ce5..9ede143ccef1 100644 >> --- a/arch/arm64/kvm/mmu.c >> +++ b/arch/arm64/kvm/mmu.c >> @@ -1603,6 +1603,10 @@ static int user_mem_abort(struct kvm_vcpu >> *vcpu, phys_addr_t fault_ipa, >> if (logging_active) { >> force_pte = true; >> vma_shift = PAGE_SHIFT; >> + } else if (kvm_is_realm(kvm)) { >> + // Force PTE level mappings for realms >> + force_pte = true; >> + vma_shift = PAGE_SHIFT; >> } else { >> vma_shift = get_vma_page_shift(vma, hva); >> } > > Since a memory abort is specific to a vCPU instead of a VM, so > vcpu_is_rec() > instead of kvm_is_realm() is more accurate for the check. Besides, it looks > duplicate to the check added by "PATCH[20/43] arm64: RME: Runtime faulting > of memory", which is as below. > > /* FIXME: We shouldn't need to disable this for realms */ > if (vma_pagesize == PAGE_SIZE && !(force_pte || device || > kvm_is_realm(kvm))) { > > ^^^^^^^^^^^^^^^^^ > Can be > dropped now. Indeed, thanks for that - one less FIXME ;) Thanks, Steve > Thanks, > Gavin > >
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index e88714903ce5..9ede143ccef1 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1603,6 +1603,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, if (logging_active) { force_pte = true; vma_shift = PAGE_SHIFT; + } else if (kvm_is_realm(kvm)) { + // Force PTE level mappings for realms + force_pte = true; + vma_shift = PAGE_SHIFT; } else { vma_shift = get_vma_page_shift(vma, hva); }
Always split up huge pages to avoid problems managing huge pages. There are two issues currently: 1. The uABI for the VMM allows populating memory on 4k boundaries even if the underlying allocator (e.g. hugetlbfs) is using a larger page size. Using a memfd for private allocations will push this issue onto the VMM as it will need to respect the granularity of the allocator. 2. The guest is able to request arbitrary ranges to be remapped as shared. Again with a memfd approach it will be up to the VMM to deal with the complexity and either overmap (need the huge mapping and add an additional 'overlapping' shared mapping) or reject the request as invalid due to the use of a huge page allocator. For now just break everything down to 4k pages in the RMM controlled stage 2. Signed-off-by: Steven Price <steven.price@arm.com> --- arch/arm64/kvm/mmu.c | 4 ++++ 1 file changed, 4 insertions(+)