lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9b8a3ee-b35b-5c45-5042-2466607abcd0@linux.microsoft.com>
Date: Mon, 27 Oct 2025 14:21:56 -0700
From: Mukesh R <mrathor@...ux.microsoft.com>
To: alex.williamson@...hat.com, joe@...ches.com
Cc: kvm@...r.kernel.org,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
 "wei.liu@...nel.org" <wei.liu@...nel.org>
Subject: [RFC] Making vma_to_pfn() public (due to vm_pgoff change)

Hi Alex,

This regards vfio passthru support on hyperv running linux as dom0 aka
root. At a high level, cloud hypervisor uses vfio for set up as usual,
then maps the mmio ranges via the hyperv linux driver ioctls.

Over a year ago, when working on this I had used vm_pgoff to get the pfn
for the mmio, that was 5.15 and early 6.x kernels. Now that I am porting
to 6.18 for upstreaming, I noticed:

commit aac6db75a9fc
Author: Alex Williamson <alex.williamson@...hat.com>
    vfio/pci: Use unmap_mapping_range()

changed the behavior and vm_pgoff is no longer holding the pfn. In light
of that, I wondered if the following minor change, making vma_to_pfn() 
public (after renaming it), would be acceptable to you.

Thanks,
-Mukesh

-----------------------------------------------------------------------------
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 7dcf5439dedc..43083a16d8a2 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1628,7 +1628,7 @@ void vfio_pci_memory_unlock_and_restore(struct vfio_pci_core_device *vdev, u16 c
 	up_write(&vdev->memory_lock);
 }
 
-static unsigned long vma_to_pfn(struct vm_area_struct *vma)
+unsigned long vfio_pci_vma_to_pfn(struct vm_area_struct *vma)
 {
 	struct vfio_pci_core_device *vdev = vma->vm_private_data;
 	int index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);
@@ -1647,7 +1647,7 @@ static vm_fault_t vfio_pci_mmap_huge_fault(struct vm_fault *vmf,
 	struct vfio_pci_core_device *vdev = vma->vm_private_data;
 	unsigned long addr = vmf->address & ~((PAGE_SIZE << order) - 1);
 	unsigned long pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
-	unsigned long pfn = vma_to_pfn(vma) + pgoff;
+	unsigned long pfn = vfio_pci_vma_to_pfn(vma) + pgoff;
 	vm_fault_t ret = VM_FAULT_SIGBUS;
 
 	if (order && (addr < vma->vm_start ||
diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
index f541044e42a2..88925c6b8a22 100644
--- a/include/linux/vfio_pci_core.h
+++ b/include/linux/vfio_pci_core.h
@@ -119,6 +119,7 @@ ssize_t vfio_pci_core_read(struct vfio_device *core_vdev, char __user *buf,
 		size_t count, loff_t *ppos);
 ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *buf,
 		size_t count, loff_t *ppos);
+unsigned long vfio_pci_vma_to_pfn(struct vm_area_struct *vma);
 int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma);
 void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count);
 int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf);



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ