Re: [PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags

[Ankit Agrawal <ankita@nvidia.com>]

>> In this case KVM still needs to know the properties of the device. Not
>> sure how it could best do this without a vma.
>
> Well, the idea I hope to succeed with would annotate this kind of
> information inside the page list that would be exchanged through the
> FD.
>
> There is an monstrous thread here about this topic:
>
>
>
> https://lore.kernel.org/all/20250107142719.179636-1-yilun.xu@linux.intel.com/
>
> I can't find it in the huge thread but I did explain some thoughts on
> how it could work
>
> Jason

Hi,

Based on the recent discussions, I gather that having a KVM_CAP
to expose the support for cacheable PFNMAP to the VMM would be
useful from VM migration point of view.

However it appears that the memslot flag isn't a must-have. The memslot
flag cannot influence the KVM code anyways. For FWB, the PFNMAP would
be cacheable and userspace should just assume S2FWB behavior; it would
be a security bug otherwise as Jason pointed earlier (S1 cacheable,
S2 noncacheable). For !FWB, a cacheable PFNMAP could not be allowed
and VMM shouldn't attempt to create memslot at all by referring the cap.

Also, can we take the fd based communication path between VFIO
and KVM separately?

I am planning to send out the series with the following implementation.
Please let me know if there are any disagreements or concerns.

1. Block cacheable PFN map in memslot creation (kvm_arch_prepare_memory_region)
and during fault handling (user_mem_abort()).
2. Enable support for cacheable PFN maps if S2FWB is enabled by following
the vma pgprot (this patch).
3. Add and expose the new KVM cap to expose cacheable PFNMAP (set to false
for !FWB).