From: Jason Gunthorpe <jgg@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
kevin.tian@intel.com, will@kernel.org, joro@8bytes.org,
suravee.suthikulpanit@amd.com, robin.murphy@arm.com,
dwmw2@infradead.org, shuah@kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org, eric.auger@redhat.com,
jean-philippe@linaro.org, mdf@kernel.org, mshavit@google.com,
shameerali.kolothum.thodi@huawei.com, smostafa@google.com,
yi.l.liu@intel.com, aik@amd.com, zhangfei.gao@linaro.org,
patches@lists.linux.dev
Subject: Re: [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its related struct
Date: Tue, 22 Oct 2024 10:15:54 -0300 [thread overview]
Message-ID: <20241022131554.GF13034@nvidia.com> (raw)
In-Reply-To: <dd7eb37f-13c6-4c6e-8adc-954ad9974b93@linux.intel.com>
On Tue, Oct 22, 2024 at 04:59:07PM +0800, Baolu Lu wrote:
> Is it feasible to make vIOMMU object more generic, rather than strictly
> tying it to nested translation? For example, a normal paging domain that
> translates gPAs to hPAs could also have a vIOMMU object associated with
> it.
>
> While we can only support vIOMMU object allocation uAPI for S2 paging
> domains in the context of this series, we could consider leaving the
> option open to associate a vIOMMU object with other normal paging
> domains that are not a nested parent?
Why? The nested parent flavour of the domain is basically free to
create, what reason would be to not do that?
If the HW doesn't support it, then does the HW really need/support a
VIOMMU?
I suppose it could be made up to the driver, but for now I think we
should leave it as is in the core code requiring it until we have a
reason to relax it.
Jason
next prev parent reply other threads:[~2024-10-22 13:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 0:19 [PATCH v4 00/11] iommufd: Add vIOMMU infrastructure (Part-1) Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 01/11] iommufd: Move struct iommufd_object to public iommufd header Nicolin Chen
2024-10-25 8:34 ` Tian, Kevin
2024-10-22 0:19 ` [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its related struct Nicolin Chen
2024-10-22 2:28 ` Baolu Lu
2024-10-22 4:40 ` Nicolin Chen
2024-10-22 8:59 ` Baolu Lu
2024-10-22 13:15 ` Jason Gunthorpe [this message]
2024-10-23 1:48 ` Baolu Lu
2024-10-25 8:47 ` Tian, Kevin
2024-10-25 15:24 ` Jason Gunthorpe
2024-10-28 2:30 ` Tian, Kevin
2024-10-22 0:19 ` [PATCH v4 03/11] iommufd: Add iommufd_verify_unfinalized_object Nicolin Chen
2024-10-25 8:49 ` Tian, Kevin
2024-10-22 0:19 ` [PATCH v4 04/11] iommufd/viommu: Add IOMMU_VIOMMU_ALLOC ioctl Nicolin Chen
2024-10-25 8:59 ` Tian, Kevin
2024-10-25 16:22 ` Nicolin Chen
2024-10-25 9:05 ` Tian, Kevin
2024-10-25 16:17 ` Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 05/11] iommufd: Add domain_alloc_nested op to iommufd_viommu_ops Nicolin Chen
2024-10-25 9:00 ` Tian, Kevin
2024-10-22 0:19 ` [PATCH v4 06/11] iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT_ALLOC Nicolin Chen
2024-10-25 9:04 ` Tian, Kevin
2024-10-25 16:14 ` Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 07/11] iommufd/selftest: Add refcount to mock_iommu_device Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 08/11] iommufd/selftest: Add IOMMU_VIOMMU_TYPE_SELFTEST Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 09/11] iommufd/selftest: Add IOMMU_VIOMMU_ALLOC test coverage Nicolin Chen
2024-10-22 0:19 ` [PATCH v4 10/11] Documentation: userspace-api: iommufd: Update vIOMMU Nicolin Chen
2024-10-25 9:11 ` Tian, Kevin
2024-10-22 0:19 ` [PATCH v4 11/11] iommu/arm-smmu-v3: Add IOMMU_VIOMMU_TYPE_ARM_SMMUV3 support Nicolin Chen
2024-10-25 9:18 ` Tian, Kevin
2024-10-25 15:41 ` Jason Gunthorpe
2024-10-25 8:34 ` [PATCH v4 00/11] iommufd: Add vIOMMU infrastructure (Part-1) Tian, Kevin
2024-10-25 15:42 ` Jason Gunthorpe
2024-10-28 2:35 ` Tian, Kevin
2024-10-25 16:28 ` Nicolin Chen
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=20241022131554.GF13034@nvidia.com \
--to=jgg@nvidia.com \
--cc=aik@amd.com \
--cc=baolu.lu@linux.intel.com \
--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-arm-kernel@lists.infradead.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