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: Thu, 14 Nov 2024 12:20:10 -0400 [thread overview]
Message-ID: <20241114162010.GP35230@nvidia.com> (raw)
In-Reply-To: <ZzVsEmzc1UyDdi//@Asurada-Nvidia>
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.
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.
Jason
next prev parent reply other threads:[~2024-11-14 16:20 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 [this message]
2024-11-15 22:07 ` Nicolin Chen
2024-11-16 0:34 ` Jason Gunthorpe
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=20241114162010.GP35230@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 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).