On Wed, Dec 06, 2023 at 06:58:44PM +0000, Catalin Marinas wrote: > -------------8<---------------------------- > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > index 1929103ee59a..b89d2dfcd534 100644 > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -1863,7 +1863,7 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma > * See remap_pfn_range(), called from vfio_pci_fault() but we can't > * change vm_flags within the fault handler. Set them now. > */ > - vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); > + vm_flags_set(vma, VM_VFIO | VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); > vma->vm_ops = &vfio_pci_mmap_ops; > > return 0; > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 418d26608ece..6df46fd7836a 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp); > # define VM_UFFD_MINOR VM_NONE > #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ > > +#ifdef CONFIG_64BIT > +#define VM_VFIO_BIT 39 > +#define VM_VFIO BIT(VM_VFIO_BIT) > +#else > +#define VM_VFIO 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) > -------------8<---------------------------- > > In KVM, Akita's patch would take this into account, not just rely on > "device==true". Yes, Ankit let's try this please. I would not call it VM_VFIO though VM_VFIO_ALLOW_WC ? Introduce it in a separate patch and summarize this thread, with a suggested-by from Catalin :) Cc Sean Christopherson <seanjc@xxxxxxxxxx> too as x86 kvm might support the idea > I think that's a key argument. The VMM cannot, on its own, configure the > BAR and figure a way to communicate this to the guest. We could invent > some para-virtualisation/trapping mechanism but that's unnecessarily > complicated. In the DPDK case, DPDK both configures and interacts with > the device. In the VMM/VM case, we need the VM to do this, we can't > split the configuration in VMM and interaction with the device in the > VM. Yes Thanks, Jason
