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

[Ankit Agrawal <ankita@nvidia.com>]

Hi, summarizing the discussion so far and outlining the next steps. The key points
are as follows:
1. KVM cap to expose whether the kernel supports mapping cacheable PFNMAP:
If the host doesn't have FWB, then the capability doesn't exist. Jason, Oliver, Caitlin
and Sean points that this may not be required as userspace do not have
much choice anyways. KVM has to follow the PTEs and userspace cannot ask
for something different. However, Marc points that enumerating FWB support
would allow userspace to discover the support and prevent live-migration
across FWB and non-FWB hosts. Jason suggested that this may still be fine as
we have already built in VFIO side protection where a live migration can be
attempted and then fail because of late-detected HW incompatibilities.

2. New memslot flag that VMM passes at memslot registration:
Discussion point that this is not necessary and KVM should just follow the
VMA pgprot.

3. Fallback path handling for PFNMAP when the FWB is not set:
Discussion points that there shouldn't be any fallback path and the memslot
should just fail. i.e. KVM should not allow degrading cachable to non-cachable
when it can't do flushing. This is to prevent the potential security issue
pointed by Jason (S1 cacheable, S2 noncacheable).


So AIU, the next step is to send out the updated series with the following patches:
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), pending maintainers' feedback on the necessity of this capability.

Please let me know if there are any inaccuracies.

Thanks
Ankit Agrawal