Messages in this thread | | | Date | Wed, 2 Jun 2021 10:49:50 +0000 | From | Quentin Perret <> | Subject | Re: [PATCH v5 2/6] KVM: arm64: Move D-cache flush to the fault handlers |
| |
On Wednesday 02 Jun 2021 at 11:19:49 (+0100), Marc Zyngier wrote: > On Thu, 15 Apr 2021 12:50:28 +0100, > > @@ -583,6 +589,7 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, > > { > > kvm_pte_t new, old = *ptep; > > u64 granule = kvm_granule_size(level), phys = data->phys; > > + struct kvm_pgtable *pgt = data->mmu->pgt; > > struct kvm_pgtable_mm_ops *mm_ops = data->mm_ops; > > > > if (!kvm_block_mapping_supported(addr, end, phys, level)) > > @@ -606,6 +613,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, > > stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); > > } > > > > + /* Perform CMOs before installation of the guest stage-2 PTE */ > > + if (pgt->flags & KVM_PGTABLE_S2_GUEST) { > > + if (stage2_pte_cacheable(pgt, new) && !stage2_has_fwb(pgt)) > > + __flush_dcache_area(mm_ops->phys_to_virt(phys), > > + granule); > > + } > > Rather than this, why not provide new callbacks in mm_ops, even if we > have to provide one that is specific to guests (and let the protected > stuff do its own thing)?
Ack, an optional callback in the mm_ops sounds much nicer.
> One thing I really dislike though is that the page-table code is > starting to be littered with things that are not directly related to > page tables. We are re-creating the user_mem_abort() mess in a > different place.
+1, we should probably keep the page-table code as close as possible to a standalone and architecturally-compliant library as opposed to a mess of unrelated logic, simply because that will lead to a cleaner and more maintainable design in the long run, and because that will ease the interoperability with EL2 in protected mode.
Thanks, Quentin
| |