On Wed, Mar 19, 2025 at 02:04:29PM -0300, Jason Gunthorpe wrote: > On Wed, Mar 19, 2025 at 12:01:29AM -0700, Oliver Upton wrote: > > You have a very good point that KVM is broken for cacheable PFNMAP'd > > crap since we demote to something non-cacheable, and maybe that > > deserves fixing first. Hopefully nobody notices that we've taken away > > the toys... > > Fixing it is either faulting all access attempts or mapping it > cachable to the S2 (as this series is trying to do).. As I replied earlier, it might be worth doing both - fault on !FWB hardware (or rather reject the memslot creation), cacheable S2 otherwise. > > I'm less worried about recovery and more focused on userspace being > > able to understand what happened. Otherwise we may get folks complaining > > about the ioctl failing "randomly" on certain machines. > > Even today something like qemu doesn't know that VFIO has created a > cachable mmap, so it would need a bunch more work to feed everything > through as proposed here. I came to the same conclusion, qemu wouldn't be able to pass any KVM_MEMORY_* flag to request cacheable since it doesn't know what attributes it got from VFIO. You need a side-channel communication between the host VFIO driver and KVM. With Ankit's proposal, that's the Stage 1 MMU attributes for the qemu mapping. -- Catalin
