>> insufficient information and uncertainity in the behavior of > > s/uncertainity/uncertainty/ Ack. >> non PCI drivers. >> >> Add a new flag VM_ALLOW_ANY_UNCACHED to indicate KVM that the device >> is WC capable and these S2 changes can be extended to it. KVM can use >> this flag to activate the code. >> > > MM people will stumble only over this commit at some point, looking for > details. It might make sense to add a bit more details on the underlying > problem (user space tables vs. stage-1 vs. stage-2) and why we want to > have a different mapping in user space compared to stage-1. > > Then, describe that the VMA flag was found to be the simplest and > cleanest way to communicate this information from VFIO to KVM. Okay, I'll work on the commit message and describe in more details in the next version. >> +/* >> + * This flag is used to connect VFIO to arch specific KVM code. It >> + * indicates that the memory under this VMA is safe for use with any >> + * non-cachable memory type inside KVM. Some VFIO devices, on some >> + * platforms, are thought to be unsafe and can cause machine crashes >> + * if KVM does not lock down the memory type. >> + */ >> +#ifdef CONFIG_64BIT >> +#define VM_ALLOW_ANY_UNCACHED_BIT 39 >> +#define VM_ALLOW_ANY_UNCACHED BIT(VM_ALLOW_ANY_UNCACHED_BIT) >> +#else >> +#define VM_ALLOW_ANY_UNCACHED VM_NONE >> +#endif >> + >> /* Bits set in the VMA until the stack is in its final location */ >> #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY) >> > > It's not perfect (very VFIO <-> KVM specific right now, VMA flags feel a > bit wrong), but it certainly easier and cleaner than any alternatives I > could think of. > > Acked-by: David Hildenbrand <david@xxxxxxxxxx> Thanks! FWIW, it was found the cleanest way to restrict the changes to vfio-pci.
