Re: [PATCH v3 4/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest

Yu Zhang <[email protected]>
Newsgroups dev.linux.lists.iommu,org.kernel.vger.linux-arch,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci
Message-ID <x6tm2k4b4fagvnpqwvwwwc5u76md7xrnann5okduauieuimj52@svvj6petg2n2>
On Thu, Aug 13, 2026 at 11:02:07AM -0700, Easwar Hariharan wrote:
> On 8/11/2026 08:50, Yu Zhang wrote:
> > Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
> > This driver implements stage-1 IO translation within the guest OS.
> > It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
> > for:
> >  - Capability discovery
> >  - Domain allocation, configuration, and deallocation
> >  - Device attachment and detachment
> >  - IOTLB invalidation
> > 
> > The driver constructs x86-compatible stage-1 IO page tables in the
> > guest memory using consolidated IO page table helpers. This allows
> > the guest to manage stage-1 translations independently of vendor-
> > specific drivers (like Intel VT-d or AMD IOMMU).
> > 
> > Hyper-V consumes this stage-1 IO page table when a device domain is
> > created and configured, and nests it with the host's stage-2 IO page
> > tables, therefore eliminating the VM exits for guest IOMMU mapping
> > operations. For unmapping operations, VM exits to perform the IOTLB
> > flush are still unavoidable.
> > 
> > Guest hibernation and resume are not supported by this initial
> > implementation. The guest-owned stage-1 page tables reside in guest
> > memory and are preserved in the hibernation image. However, the image
> > does not by itself preserve the Hyper-V device-domain objects or their
> > device attachments, and the current pvIOMMU interface does not define
> > whether or how Hyper-V restores that state.
> > 
> > To identify a device in its hypercall interface, the driver looks up the
> > logical device ID prefix registered for the device's PCI domain (see the
> > logical device ID registry in hv_common.c) and combines it with the PCI
> > function number of the endpoint device.
> > 
> > Co-developed-by: Wei Liu <[email protected]>
> > Signed-off-by: Wei Liu <[email protected]>
> > Co-developed-by: Easwar Hariharan <[email protected]>
> > Signed-off-by: Easwar Hariharan <[email protected]>
> > Signed-off-by: Yu Zhang <[email protected]>
> > ---
> >  arch/x86/hyperv/hv_init.c             |   4 +
> >  arch/x86/include/asm/mshyperv.h       |   4 +
> >  drivers/iommu/Kconfig                 |   1 +
> >  drivers/iommu/hyperv/Kconfig          |  16 +
> >  drivers/iommu/hyperv/Makefile         |   1 +
> >  drivers/iommu/hyperv/hv-iommu-guest.c | 632 ++++++++++++++++++++++++++
> >  drivers/iommu/hyperv/iommu.h          |  50 ++
> >  7 files changed, 708 insertions(+)
> >  create mode 100644 drivers/iommu/hyperv/Kconfig
> >  create mode 100644 drivers/iommu/hyperv/hv-iommu-guest.c
> >  create mode 100644 drivers/iommu/hyperv/iommu.h
> > 
> Seems like this is missing a change to MAINTAINERS. I'd suggest making a new section
> and adding both the IOMMU and Hyper-V lists. As it stands, the IOMMU list will get no
> notification of changes to this driver.
> 

Thanks for your remind, Easwar. 

We do intend to maintain the Linux guest pvIOMMU driver. I am just not
sure whether it needs a separate section in the MAINTAINERS file, since
drivers/iommu/hyperv/ is already covered by both the Hyper-V and generic
IOMMU entries, and get_maintainer.pl returns both mailing lists and sets
of maintainers. Therefore I don't see a notification gap that requires a
separate entry.
                                                                                                                                                        
Do the Hyper-V and IOMMU maintainers have a preference here?

B.R.
Yu
> Thanks,
> Easwar (he/him)
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.