From: Jacob Pan <jacob.pan@linux.microsoft.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Vipin Sharma <vipinsh@google.com>,
bhelgaas@google.com, alex.williamson@redhat.com,
pasha.tatashin@soleen.com, dmatlack@google.com, graf@amazon.com,
pratyush@kernel.org, gregkh@linuxfoundation.org,
chrisl@kernel.org, rppt@kernel.org, skhawaja@google.com,
parav@nvidia.com, saeedm@nvidia.com, kevin.tian@intel.com,
jrhilke@google.com, david@redhat.com, jgowans@amazon.com,
dwmw2@infradead.org, epetron@amazon.de, junaids@google.com,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH 06/21] vfio/pci: Accept live update preservation request for VFIO cdev
Date: Tue, 28 Oct 2025 10:39:45 -0700 [thread overview]
Message-ID: <20251028103945.0000716e@linux.microsoft.com> (raw)
In-Reply-To: <20251028132855.GJ760669@ziepe.ca>
On Tue, 28 Oct 2025 10:28:55 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Mon, Oct 27, 2025 at 01:44:30PM -0700, Jacob Pan wrote:
> > I have a separate question regarding noiommu devices. I’m currently
> > working on adding noiommu mode support for VFIO cdev under iommufd.
> >
>
> Oh how is that going? I was just thinking about that again..
>
I initially tried to create a special VFIO no-iommu iommu_domain
without an iommu driver, but I found it difficult without iommu_group
and other machinery. I also had a special vfio_device_ops
vfio_pci_noiommu_ops with special vfio_iommufd_noiommu_bind to create
iommufd_acess object as in Yi's original patch.
My current approach is that I have a special noiommu driver that handles
the special iommu_domain. It seems much cleaner though some extra code
overhead. I have a working prototype that has:
# tree /dev/vfio/
/dev/vfio/
|-- 7
|-- devices
| `-- noiommu-vfio0
`-- vfio
And the typical:
/sys/class/iommu/noiommu/
|-- devices
| |-- 0000:00:00.0 -> ../../../../pci0000:00/0000:00:00.0
| |-- 0000:00:01.0 -> ../../../../pci0000:00/0000:00:01.0
| |-- 0000:00:02.0 -> ../../../../pci0000:00/0000:00:02.0
| |-- 0000:00:03.0 -> ../../../../pci0000:00/0000:00:03.0
| |-- 0000:00:04.0 -> ../../../../pci0000:00/0000:00:04.0
| |-- 0000:00:05.0 -> ../../../../pci0000:00/0000:00:05.0
| |-- 0000:01:00.0 -> ../../../../pci0000:00/0000:00:04.0/0000:0
The following user test can pass:
1. __iommufd = open("/dev/iommu", O_RDWR);
2. devfd = open a noiommu cdev
3. ioas_id = ioas_alloc(__iommufd)
4. iommufd_bind(__iommufd, devfd)
5. successfully do an ioas map, e.g.
ioctl(iommufd, IOMMU_IOAS_MAP, &map)
This will call pfn_reader_user_pin() but the noiommu driver does
nothing for mapping.
I am still debugging some cases, would like to have a direction check
before going too far.
> After writing the generic pt self test it occured to me we now have
> enough infrastructure for iommufd to internally create its own
> iommu_domain with a AMDv1 page table for the noiommu devices. It would
> then be so easy to feed that through the existing machinery and have
> all the pinning/etc work.
>
Could you elaborate a little more? noiommu devices don't have page
tables. Are you saying iommufd can create its own iommu_domain w/o a
vendor iommu driver? Let me catch up with your v7 :)
> Then only an ioctl to read back the physical addresses from this
> special domain would be needed
>
Yes, that was part of your original suggestion to avoid /proc pagemap.
I have not added that yet. Do you think this warrant a new ioctl or
just return it in
struct iommu_ioas_map map = {
.size = sizeof(map),
.flags = IOMMU_IOAS_MAP_READABLE,
.ioas_id = ioas_id,
.iova = iova,
.user_va = uvaddr,
.length = size,
};
> It actually sort of feels pretty easy..
>
> Jason
next prev parent reply other threads:[~2025-10-28 17:39 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-18 0:06 [RFC PATCH 00/21] VFIO live update support Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 01/21] selftests/liveupdate: Build tests from the selftests/liveupdate directory Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 02/21] selftests/liveupdate: Create library of core live update ioctls Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 03/21] selftests/liveupdate: Move do_kexec.sh script to liveupdate/lib Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 04/21] selftests/liveupdate: Move LUO ioctls calls to liveupdate library Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 05/21] vfio/pci: Register VFIO live update file handler to Live Update Orchestrator Vipin Sharma
2025-10-18 0:06 ` [RFC PATCH 06/21] vfio/pci: Accept live update preservation request for VFIO cdev Vipin Sharma
2025-10-27 20:44 ` Jacob Pan
2025-10-28 13:28 ` Jason Gunthorpe
2025-10-28 17:39 ` Jacob Pan [this message]
2025-10-29 16:21 ` Jason Gunthorpe
2025-10-18 0:06 ` [RFC PATCH 07/21] vfio/pci: Store VFIO PCI device preservation data in KHO for live update Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 08/21] vfio/pci: Retrieve preserved VFIO device for Live Update Orechestrator Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 09/21] vfio/pci: Add Live Update finish callback implementation Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 10/21] PCI: Add option to skip Bus Master Enable reset during kexec Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 11/21] vfio/pci: Skip clearing bus master on live update device " Vipin Sharma
2025-10-18 7:09 ` Lukas Wunner
2025-10-18 22:19 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 12/21] vfio/pci: Skip clearing bus master on live update restored device Vipin Sharma
2025-10-20 21:29 ` David Matlack
2025-10-20 22:39 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 13/21] vfio/pci: Preserve VFIO PCI config space through live update Vipin Sharma
2025-10-18 14:59 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 14/21] vfio/pci: Skip device reset on live update restored device Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 15/21] PCI: Make PCI saved state and capability structs public Vipin Sharma
2025-10-18 7:17 ` Lukas Wunner
2025-10-18 22:36 ` Vipin Sharma
2025-10-18 23:11 ` Jason Gunthorpe
2025-10-20 23:49 ` Vipin Sharma
2025-10-22 17:45 ` David Matlack
2025-10-22 17:51 ` Jason Gunthorpe
2025-10-22 17:53 ` Jason Gunthorpe
2025-10-19 8:15 ` Lukas Wunner
2025-10-20 23:54 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 16/21] vfio/pci: Save and restore the PCI state of the VFIO device Vipin Sharma
2025-10-18 7:25 ` Lukas Wunner
2025-10-18 22:44 ` Vipin Sharma
2025-10-18 15:02 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 17/21] vfio/pci: Disable interrupts before going live update kexec Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 18/21] vfio: selftests: Build liveupdate library in VFIO selftests Vipin Sharma
2025-10-20 20:50 ` David Matlack
2025-10-20 23:55 ` Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 19/21] vfio: selftests: Initialize vfio_pci_device using a VFIO cdev FD Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 20/21] vfio: selftests: Add VFIO live update test Vipin Sharma
2025-10-18 0:07 ` [RFC PATCH 21/21] vfio: selftests: Validate vconfig preservation of VFIO PCI device during live update Vipin Sharma
2025-10-18 17:21 ` [RFC PATCH 00/21] VFIO live update support Jason Gunthorpe
2025-10-18 22:53 ` Vipin Sharma
2025-10-18 23:06 ` Jason Gunthorpe
2025-10-20 23:30 ` Vipin Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251028103945.0000716e@linux.microsoft.com \
--to=jacob.pan@linux.microsoft.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=dmatlack@google.com \
--cc=dwmw2@infradead.org \
--cc=epetron@amazon.de \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@ziepe.ca \
--cc=jgowans@amazon.com \
--cc=jrhilke@google.com \
--cc=junaids@google.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=saeedm@nvidia.com \
--cc=skhawaja@google.com \
--cc=vipinsh@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).