QEMU-Devel Archive mirror
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@redhat.com>
To: Zhenzhong Duan <zhenzhong.duan@intel.com>, qemu-devel@nongnu.org
Cc: alex.williamson@redhat.com, eric.auger@redhat.com,
	mst@redhat.com, peterx@redhat.com, jasowang@redhat.com,
	jgg@nvidia.com, nicolinc@nvidia.com, joao.m.martins@oracle.com,
	kevin.tian@intel.com, yi.l.liu@intel.com, chao.p.peng@intel.com
Subject: Re: [PATCH v3 00/19] Add a host IOMMU device abstraction to check with vIOMMU
Date: Fri, 3 May 2024 16:04:25 +0200	[thread overview]
Message-ID: <c245b234-60d5-4ee6-a947-c7526d58698e@redhat.com> (raw)
In-Reply-To: <20240429065046.3688701-1-zhenzhong.duan@intel.com>

On 4/29/24 08:50, Zhenzhong Duan wrote:
> Hi,
> 
> The most important change in this version is instroducing a common
> HostIOMMUDeviceCaps structure in HostIOMMUDevice and a new interface
> between vIOMMU and HostIOMMUDevice.
> 
> HostIOMMUDeviceClass::realize() is introduced to initialize
> HostIOMMUDeviceCaps and other fields of HostIOMMUDevice variants.
> 
> HostIOMMUDeviceClass::check_cap() is introduced to query host IOMMU
> device capabilities.
> 
> After the change, part2 is only 3 patches, so merge it with part1 to be
> a single prerequisite series, same for changelog. If anyone doesn't like
> that, I can split again.
> 
> The class tree is as below:
> 
>                                HostIOMMUDevice
>                                       | .caps
>                                       | .realize()
>                                       | .check_cap()
>                                       |
>              .-----------------------------------------------.
>              |                        |                      |
> HostIOMMUDeviceLegacyVFIO  {HostIOMMUDeviceLegacyVDPA}  HostIOMMUDeviceIOMMUFD
>              | .vdev                  | {.vdev}              | .iommufd
>                                                              | .devid
>                                                              | [.ioas_id]
>                                                              | [.attach_hwpt()]
>                                                              | [.detach_hwpt()]
>                                                              |
>                                            .----------------------.
>                                            |                      |
>                         HostIOMMUDeviceIOMMUFDVFIO  {HostIOMMUDeviceIOMMUFDVDPA}
>                                            | .vdev                | {.vdev}
> 
> * The attributes in [] will be implemented in nesting series.
> * The classes in {} will be implemented in future.
> * .vdev in different class points to different agent device,
> * i.e., for VFIO it points to VFIODevice.
> 
> PATCH1-4: Introduce HostIOMMUDevice and its sub classes
> PATCH5-11: Introduce HostIOMMUDeviceCaps, implement .realize() and .check_cap() handler
> PATCH12-16: Create HostIOMMUDevice instance and pass to vIOMMU
> PATCH17-19: Implement compatibility check between host IOMMU and vIOMMU(intel_iommu)
> 
> Qemu code can be found at:
> https://github.com/yiliu1765/qemu/tree/zhenzhong/iommufd_nesting_preq_v3
> 
> Besides the compatibility check in this series, in nesting series, this
> host IOMMU device is extended for much wider usage. For anyone interested
> on the nesting series, here is the link:
> https://github.com/yiliu1765/qemu/tree/zhenzhong/iommufd_nesting_rfcv2


v4 should be a good candidate, we will need feedback from the vIOMMU
maintainers though.

However, have you considered another/complementary approach which
would be to create an host IOMMU (iommufd) backend object and a vIOMMU
device object together for each vfio-pci device being plugged in the
machine ?

Something like,
     
     -device pcie-root-port,port=23,chassis=8,id=pci.8,bus=pcie.0 \
     -object iommufd,id=iommufd1 \
     -device intel-iommu,intremap=on,device-iotlb=on,caching-mode=on,iommufd=iommufd1 \
     -device vfio-pci,host=0000:08:10.0,bus=pci.1,iommufd=iommufd0

The vIOMMU device would be linked to the host IOMMU (iommufd) backend
object at realize time and it would simplify the discovery of the host
IOMMU properties. The implementation would be more straight forward.

That said, I didn't study deeply what needs to be done. The vIOMMU
implementation is not ready yet to support multiple instances and some
massaging is needed to change that first.

Thanks,

C.

       



  parent reply	other threads:[~2024-05-03 14:04 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  6:50 [PATCH v3 00/19] Add a host IOMMU device abstraction to check with vIOMMU Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 01/19] backends: Introduce HostIOMMUDevice abstract Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 02/19] vfio/container: Introduce HostIOMMUDeviceLegacyVFIO device Zhenzhong Duan
2024-04-30  7:51   ` Cédric Le Goater
2024-04-30  9:13     ` Duan, Zhenzhong
2024-04-30 12:00       ` Cédric Le Goater
2024-04-29  6:50 ` [PATCH v3 03/19] backends/iommufd: Introduce abstract HostIOMMUDeviceIOMMUFD device Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 04/19] vfio/iommufd: Introduce HostIOMMUDeviceIOMMUFDVFIO device Zhenzhong Duan
2024-04-30  7:52   ` Cédric Le Goater
2024-04-30  9:25     ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 05/19] backends/host_iommu_device: Introduce HostIOMMUDeviceCaps Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30  9:55     ` Duan, Zhenzhong
2024-04-30 12:01       ` Cédric Le Goater
2024-05-07  6:11   ` Cédric Le Goater
2024-05-07  6:24     ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 06/19] range: Introduce range_get_last_bit() Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30  9:58     ` Duan, Zhenzhong
2024-05-02 10:30       ` Cédric Le Goater
2024-05-06  6:45         ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 07/19] vfio/container: Implement HostIOMMUDeviceClass::realize() handler Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30  9:59     ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 08/19] backends/iommufd: Introduce helper function iommufd_backend_get_device_info() Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30 10:06     ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 09/19] vfio/iommufd: Implement HostIOMMUDeviceClass::realize() handler Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 10/19] vfio/container: Implement HostIOMMUDeviceClass::check_cap() handler Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 11/19] backends/iommufd: " Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30 10:06     ` Duan, Zhenzhong
2024-04-30 12:12       ` Cédric Le Goater
2024-05-01 12:34         ` Duan, Zhenzhong
2024-05-02  8:17           ` Cédric Le Goater
2024-05-06  1:47             ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 12/19] vfio: Introduce VFIOIOMMUClass::hiod_typename attribute Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 13/19] vfio: Create host IOMMU device instance Zhenzhong Duan
2024-04-30  9:41   ` Cédric Le Goater
2024-04-30 10:16     ` Duan, Zhenzhong
2024-04-30 12:15       ` Cédric Le Goater
2024-04-29  6:50 ` [PATCH v3 14/19] hw/pci: Introduce helper function pci_device_get_iommu_bus_devfn() Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 15/19] hw/pci: Introduce pci_device_[set|unset]_iommu_device() Zhenzhong Duan
2024-05-07  7:04   ` Cédric Le Goater
2024-05-07  7:48     ` Duan, Zhenzhong
2024-05-07 12:26       ` Cédric Le Goater
2024-05-08  6:24         ` Duan, Zhenzhong
2024-04-29  6:50 ` [PATCH v3 16/19] vfio/pci: Pass HostIOMMUDevice to vIOMMU Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 17/19] intel_iommu: Extract out vtd_cap_init() to initialize cap/ecap Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 18/19] intel_iommu: Implement [set|unset]_iommu_device() callbacks Zhenzhong Duan
2024-04-29  6:50 ` [PATCH v3 19/19] intel_iommu: Check compatibility with host IOMMU capabilities Zhenzhong Duan
2024-05-03 14:04 ` Cédric Le Goater [this message]
2024-05-03 14:10   ` [PATCH v3 00/19] Add a host IOMMU device abstraction to check with vIOMMU Jason Gunthorpe
2024-05-03 14:29     ` Cédric Le Goater
2024-05-06  2:30   ` Duan, Zhenzhong
2024-05-06 12:05     ` Jason Gunthorpe
2024-05-07  2:24       ` Duan, Zhenzhong
2024-05-07 11:58         ` Jason Gunthorpe
2024-05-08  6:36           ` Duan, Zhenzhong

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=c245b234-60d5-4ee6-a947-c7526d58698e@redhat.com \
    --to=clg@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@intel.com \
    --cc=eric.auger@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kevin.tian@intel.com \
    --cc=mst@redhat.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhenzhong.duan@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).