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

[Catalin Marinas <catalin.marinas@arm.com>]

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? I feel like this is a different
use-case (e.g. more like general purpose CXL attached memory) than the
GPU one. Unless FWB implies CTR_EL0.DIC (AFAIK, it doesn't) we may be
restricting some CPUs.

-- 
Catalin