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

[Ankit Agrawal]

>> Unless FWB implies CTR_EL0.DIC (AFAIK, it doesn't) we may be
>> restricting some CPUs.
>
> Yes, it will further narrow the CPUs down.
> 
> However, we just did this discussion for BBML2 + SMMUv3 SVA. I think
> the same argument holds. If someone is crazy enough to build a CPU
> with CXLish support and uses an old core without DIC, IDC and S2FWB
> then they are going to have a bunch of work to fix the SW to support
> it. Right now we know of no system that exists like this..
>
> Jason

Catalin, do you agree if I can go ahead and add the check for
ARM64_HAS_CACHE_DIC?

>> Another CAP for executable PFNMAP then?
>
> IDK, either that or a more general cap 'support PFNMAP VMAs'?

I think it would be good to have the generic cap that is safe for
executable as well.


>> 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.
...
>> 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).
>
> I'll defer the memslot flag decision to the KVM maintainers. If we had
> one, it will enforce (2) or reject it as per (1) depending on the S1
> attributes.

Marc, Oliver, let me know your thoughts if we should add memslot flag and I'll
implement accordingly.