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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Apr 29, 2025 at 07:09:42PM +0100, Catalin Marinas wrote:
> On Tue, Apr 29, 2025 at 01:44:30PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 29, 2025 at 05:03:18PM +0100, Catalin Marinas wrote:
> > > On Tue, Apr 29, 2025 at 11:14:37AM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Apr 29, 2025 at 02:27:02PM +0100, Catalin Marinas wrote:
> > > > > BTW, we should reject exec mappings as well (they probably fail for S1
> > > > > VFIO since set_pte_at() will try to do cache maintenance).
> > > > 
> > > > To be clear the S2 should leave the mapping as execute allowed
> > > > though. Only the VM knows how it will use this memory and VM's do
> > > > actually execute out of the cachable PFNMAP VMA today. The VM will set
> > > > any execute deny/allow on its S1 table according to how it uses the
> > > > memory.
> > > 
> > > If S2 is executable, wouldn't KVM try to invalidate the I-cache and it
> > > won't have an alias to do this? Unless it doesn't end up in
> > > stage2_map_walker_try_leaf() or the walk has been flagged as skipping
> > > the CMO.
> > 
> > Okay, that does seem to have been overlooked a bit. The answer I got
> > back is:
> > 
> > Cachable PFNMAP is also relying on ARM64_HAS_CACHE_DIC also, simlar to
> > how S2FWB allows KVM to avoid flushing the D cache, that CPU cap
> > allows KVM to avoid flushing the icache and turns icache_inval_pou()
> > into a NOP.
> 
> Another CAP for executable PFNMAP then?

IDK, either that or a more general cap 'support PFNMAP VMAs'?

> I feel like this is a different
> use-case (e.g. more like general purpose CXL attached memory) than the
> GPU one. 

The GPUs we have today pretty much pretend to be CXL attached memory
so they can and do execute from it.

> 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