Messages in this thread | | | From | Ankit Agrawal <> | Subject | Re: [PATCH v1 1/2] KVM: arm64: determine memory type from VMA | Date | Sun, 10 Mar 2024 03:49:36 +0000 |
| |
Bringing this to the fore.
>> Where does that leave us for this patch? We check the VM_MTE_ALLOWED >> and check for ZONE_MOVABLE struct pages as one of the conditions for >> NORMAL? > > I think we should keep it as simple as possible and, looking at it > again, maybe even ignore vm_page_prot. Two questions though: > > 1. Does VM_IO imply vm_page_prot never having MT_NORMAL or > MT_NORMAL_TAGGED? > > 2. Do all I/O ranges (side-effects, non-RAM) mapped into a guest (and > which end up in user_mem_abort()) imply VM_IO? > > If yes to both, I think something like below would do:
How may we get the answer to these? It seems to be the logical behavior, but how can we confirm?
While we discuss on that, I am considering to send out the next version of this patch (incorporating the feedbacks on the thread) that is rebased to a commit inclusive of the recently applied KVM patch series:
[KVM: arm64: Allow the VM to select DEVICE_* and NORMAL_NC for IO memory] https://lore.kernel.org/all/20240224150546.368-1-ankita@nvidia.com/
> mte_allowed = kvm_vma_mte_allowed(vma); > noncacheable = false; // or 'device' as in user_mem_abort() > ... > if (vma->flags & VM_IO) // replaces !pfn_is_map_memory() > noncacheable = true; > else if (!mte_allowed && kvm_has_mte()) > noncaheable = true; > ... > if (noncacheable) > prot |= KVM_PGTABLE_PROT_DEVICE; // or the new KVM_PGTABLE_PROT_NC > > mte_allowed would cover DAX mappings (and, who knows, some future DAX > mapping may allow MTE and the driver explicitly set the flag). Anything > else hot-plugged into ZONE_MOVABLE should have VM_MTE_ALLOWED set or > MTE disabled altogether.
-- Catalin
| |