From: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Cédric Le Goater" <clg@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Peng, Chao P" <chao.p.peng@intel.com>
Subject: RE: [PATCH v3 00/19] Add a host IOMMU device abstraction to check with vIOMMU
Date: Wed, 8 May 2024 06:36:01 +0000 [thread overview]
Message-ID: <SJ0PR11MB6744706ACB28CBDFF05FF51F92E52@SJ0PR11MB6744.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20240507115836.GL3341011@nvidia.com>
>-----Original Message-----
>From: Jason Gunthorpe <jgg@nvidia.com>
>Subject: Re: [PATCH v3 00/19] Add a host IOMMU device abstraction to
>check with vIOMMU
>
>On Tue, May 07, 2024 at 02:24:30AM +0000, Duan, Zhenzhong wrote:
>> >On Mon, May 06, 2024 at 02:30:47AM +0000, Duan, Zhenzhong wrote:
>> >
>> >> I'm not clear how useful multiple iommufd instances support are.
>> >> One possible benefit is for security? It may bring a slightly fine-grained
>> >> isolation in kernel.
>> >
>> >No. I don't think there is any usecase, it is only harmful.
>>
>> OK, so we need to limit QEMU to only one iommufd instance.
>
>I don't know about limit, but you don't need to do extra stuff to make
>it work.
>
>The main issue will be to get all the viommu instances to share the
>same iommufd IOAS for the guest physical mapping. Otherwise each
>viommu should be largely unware of the others sharing (or not) a
>iommufd.
I see.
>
>If you can structure things properly it probably doesn't need a hard
>limit, it will just work worse.
OK, thanks for clarify.
The extra code to support multiple instances in intel_iommu is trivial.
So I'd like to keep this flexibility to user just like cdev. User can configure
QEMU cmdline to use one IOMMUFD instance easily whenever they want.
Thanks
Zhenzhong
prev parent reply other threads:[~2024-05-08 6:36 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 ` [PATCH v3 00/19] Add a host IOMMU device abstraction to check with vIOMMU Cédric Le Goater
2024-05-03 14:10 ` 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 [this message]
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=SJ0PR11MB6744706ACB28CBDFF05FF51F92E52@SJ0PR11MB6744.namprd11.prod.outlook.com \
--to=zhenzhong.duan@intel.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@intel.com \
--cc=clg@redhat.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 \
/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).