All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Yi Liu <yi.l.liu@intel.com>,
	kevin.tian@intel.com, corbet@lwn.net, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, will@kernel.org,
	robin.murphy@arm.com, dwmw2@infradead.org, shuah@kernel.org,
	iommu@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	baolu.lu@linux.intel.com, eric.auger@redhat.com,
	jean-philippe@linaro.org, mdf@kernel.org, mshavit@google.com,
	shameerali.kolothum.thodi@huawei.com, smostafa@google.com,
	aik@amd.com, zhangfei.gao@linaro.org, patches@lists.linux.dev
Subject: Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU
Date: Fri, 15 Nov 2024 20:34:43 -0400	[thread overview]
Message-ID: <20241116003443.GB35230@nvidia.com> (raw)
In-Reply-To: <ZzfGLdgykZ0M3jy5@Asurada-Nvidia>

On Fri, Nov 15, 2024 at 02:07:41PM -0800, Nicolin Chen wrote:
> On Thu, Nov 14, 2024 at 12:20:10PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 13, 2024 at 07:18:42PM -0800, Nicolin Chen wrote:
> > > > so the user would try to create vDevices with a given viommu_obj until
> > > > failure, then it would allocate another viommu_obj for the failed device.
> > > > is it? sounds reasonable.
> > > 
> > > Yes. It is the same as previously dealing with a nesting parent:
> > > test and allocate if fails. The virtual IOMMU driver in VMM can
> > > keep a list of the vIOMMU objects for each device to test.
> > 
> > The viommu object should be tied to the VMM's vIOMMU vHW object that
> > it is paravirtualizing toward the VM.
> > 
> > So we shouldn't be creating viommu objects on demand, it should be
> > created when the vIOMMU is created, and the presumably the qemu
> > command line will describe how to link vPCI/VFIO functions to vIOMMU
> > instances. If they kernel won't allow the user's configuration then it
> > should fail, IMHO.
> 
> Intel's virtual IOMMU in QEMU has one instance but could create
> two vIOMMU objects for devices behind two different pIOMMUs. So,
> in this case, it does the on-demand (or try-and-fail) approach?

I suspect Intel does need viommu at all, and if it ever does it will
not be able to have one instance..

> One corner case that Yi reminded me of was that VMM having two
> virtual IOMMUs for two devices that are behind the same pIOMMU,
> then these two virtual IOMMUs don't necessarily share the same
> vIOMMU object, i.e. VMM is allowed to allocate two vIOMMU objs?

Yes this is allowed
 
> > Some try-and-fail might be interesting to auto-provision vIOMMU's and
> > provision vPCI functions. Though I suspect we will be providing
> > information in other ioctls so something like libvirt can construct
> > the correct configuration directly.
> 
> By "auto-provision", you mean libvirt assigning devices to the
> correct virtual IOMMUs corresponding to the physical instances?
> If so, we can just match the "iommu" sysfs node of devices with
> the iommu node(s) under /sys/class/iommu/, right?

Yes

Jason

  reply	other threads:[~2024-11-16  0:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05 20:04 [PATCH v7 00/13] iommufd: Add vIOMMU infrastructure (Part-1) Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 01/13] iommufd: Move struct iommufd_object to public iommufd header Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 02/13] iommufd: Move _iommufd_object_alloc helper to a sharable file Nicolin Chen
2024-11-12 15:45   ` Jason Gunthorpe
2024-11-05 20:04 ` [PATCH v7 03/13] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its related struct Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 04/13] iommufd: Verify object in iommufd_object_finalize/abort() Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 05/13] iommufd/viommu: Add IOMMU_VIOMMU_ALLOC ioctl Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 06/13] iommufd: Add alloc_domain_nested op to iommufd_viommu_ops Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 07/13] iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT_ALLOC Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 08/13] iommufd/selftest: Add container_of helpers Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 09/13] iommufd/selftest: Prepare for mock_viommu_alloc_domain_nested() Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 10/13] iommufd/selftest: Add refcount to mock_iommu_device Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 11/13] iommufd/selftest: Add IOMMU_VIOMMU_TYPE_SELFTEST Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 12/13] iommufd/selftest: Add IOMMU_VIOMMU_ALLOC test coverage Nicolin Chen
2024-11-05 20:04 ` [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU Nicolin Chen
2024-11-07  0:56   ` Bagas Sanjaya
2024-11-07  1:35     ` Nicolin Chen
2024-11-07  3:20       ` Bagas Sanjaya
2024-11-07  4:04         ` Nicolin Chen
2024-11-08  9:01           ` Bagas Sanjaya
2024-11-12 13:15   ` Yi Liu
2024-11-14  0:18     ` Nicolin Chen
2024-11-14  3:13       ` Yi Liu
2024-11-14  3:18         ` Nicolin Chen
2024-11-14 16:20           ` Jason Gunthorpe
2024-11-15 22:07             ` Nicolin Chen
2024-11-16  0:34               ` Jason Gunthorpe [this message]
2024-11-18  6:10                 ` Yi Liu
2024-11-08 17:40 ` [PATCH v7 00/13] iommufd: Add vIOMMU infrastructure (Part-1) Jason Gunthorpe

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=20241116003443.GB35230@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aik@amd.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=mshavit@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shuah@kernel.org \
    --cc=smostafa@google.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhangfei.gao@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.