On Wed, 21 Apr 2021 07:17:44 +0100, Keqian Zhu <zhukeqian1@xxxxxxxxxx> wrote: > > Hi Gavin, > > On 2021/4/21 14:20, Gavin Shan wrote: > > Hi Keqian and Santosh, > > > > On 4/21/21 12:59 PM, Keqian Zhu wrote: > >> On 2020/10/22 0:16, Santosh Shukla wrote: > >>> The Commit:6d674e28 introduces a notion to detect and handle the > >>> device mapping. The commit checks for the VM_PFNMAP flag is set > >>> in vma->flags and if set then marks force_pte to true such that > >>> if force_pte is true then ignore the THP function check > >>> (/transparent_hugepage_adjust()). > >>> > >>> There could be an issue with the VM_PFNMAP flag setting and checking. > >>> For example consider a case where the mdev vendor driver register's > >>> the vma_fault handler named vma_mmio_fault(), which maps the > >>> host MMIO region in-turn calls remap_pfn_range() and maps > >>> the MMIO's vma space. Where, remap_pfn_range implicitly sets > >>> the VM_PFNMAP flag into vma->flags. > >> Could you give the name of the mdev vendor driver that triggers this issue? > >> I failed to find one according to your description. Thanks. > >> > > > > I think it would be fixed in driver side to set VM_PFNMAP in > > its mmap() callback (call_mmap()), like vfio PCI driver does. > > It means it won't be delayed until page fault is issued and > > remap_pfn_range() is called. It's determined from the beginning > > that the vma associated the mdev vendor driver is serving as > > PFN remapping purpose. So the vma should be populated completely, > > including the VM_PFNMAP flag before it becomes visible to user > > space. Why should that be a requirement? Lazy populating of the VMA should be perfectly acceptable if the fault can only happen on the CPU side. > > > > The example can be found from vfio driver in drivers/vfio/pci/vfio_pci.c: > > vfio_pci_mmap: VM_PFNMAP is set for the vma > > vfio_pci_mmap_fault: remap_pfn_range() is called > Right. I have discussed the above with Marc. I want to find the driver > to fix it. However, AFAICS, there is no driver matches the description... I have the feeling this is an out-of-tree driver (and Santosh email address is bouncing, so I guess we won't have much information from him). However, the simple fact that any odd driver can provide a fault handler and populate it the VMA on demand makes me think that we need to support this case. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
