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

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

On Wed, Apr 23, 2025 at 09:02:43AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 23, 2025 at 11:45:04AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 22, 2025 at 08:35:56PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Apr 22, 2025 at 02:28:18PM -0700, Oliver Upton wrote:
> > > > Wait, so userspace simultaneously doesn't know the cacheability at host
> > > > stage-1 but *does* for stage-2? 
> > > 
> > > No, it doesn't know either. The point is the VMM doesn't care about
> > > any of this. It just wants to connect KVM to VFIO and have the kernel
> > > internally negotiate the details of how that works.
> > > 
> > > There is zero value in the VMM being aware that KVM/VFIO is using
> > > cachable or non-cachable mappings because it will never touch this
> > > memory anyhow, and arguably it would be happier if it wasn't even in a
> > > VMA in the first place.
> > 
> > I think this was discussed at some point in the past - what about
> > ignoring the VMA altogether and using an fd-based approach? Keep the
> > current VFIO+vma ABI non-cacheable and introduce a new one for cacheable
> > I/O mappings, e.g. KVM_MEM_IOFD. Is there a way for VFIO to communicate
> > the attributes to KVM on the type of mapping in the absence of a VMA
> > (e.g. via the inode)? If not:
> 
> I hope to see that someday. The CC people are working in that
> direction, but we are still far from getting enough agreement from all
> the stakeholders on how that will work.
> 
> > Stage 2 could default to non-cacheable and we can add a
> > KVM_MEMORY_ATTRIBUTE_IO_WB as an option to
> 
> I don't think we should ever allow KVM to create a non-cachable
> mapping of an otherwise cachable object??

Ah, good point. So we want a strict cacheable mapping even if there is
no user/VMM mapping alias. Is it because KVM cannot do cache maintenance
on the PFNMAP or because the device does not support other memory types?
Both valid reasons though.

In this case KVM still needs to know the properties of the device. Not
sure how it could best do this without a vma.

-- 
Catalin