On Tue, Mar 18, 2025 at 08:17:36PM -0300, Jason Gunthorpe wrote: > On Tue, Mar 18, 2025 at 07:27:27PM +0000, Catalin Marinas wrote: > > Thinking some more about a KVM capability that the VMM can check, I'm > > not sure what it can do with this. The VMM simply maps something from a > > device and cannot probe the cacheability > > KVM is mirroring the MM's PTEs to the S2's PTEs. > > You can think about this differently - KVM currently has a little bug > where the MM's PTE's can say cachable but KVM will mirror it to a S2 > PTE that is forced non-cachable. KVM will not do any cache flushing to > make this safe. > > Fundamentally that discrepancy is what is being addressed > here. Cachable PTEs in the MM should be mirrored to cachable PTEs in > the S2. If we treat this as a bug (and I agree it's a potential problem if we assign devices to the guest that have cacheable VMM mappings), the first step would be to reject such memory slots, report some error to the VMM. I don't think it's worth attempting to do any cache maintenance to sync the aliases. Subsequently, this can be allowed with on FWB-capable hardware. Whether we want to expose such capability to the VMM, I guess it's harmless but I doubt the VMM would do anything with it since it doesn't know the device mapping attributes anyway. -- Catalin
