From: Baolu Lu <baolu.lu@linux.intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>,
jgg@nvidia.com, kevin.tian@intel.com, will@kernel.org
Cc: corbet@lwn.net, 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, linux-doc@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, ddutile@redhat.com, yi.l.liu@intel.com,
patches@lists.linux.dev
Subject: Re: [PATCH v3 07/14] iommufd/viommu: Add iommufd_viommu_get_vdev_id helper
Date: Thu, 19 Dec 2024 10:05:53 +0800 [thread overview]
Message-ID: <56c65e50-5890-42af-85b7-85f8a1bf5cf5@linux.intel.com> (raw)
In-Reply-To: <21d7e63b97d81d0acf9127418a67efe386787261.1734477608.git.nicolinc@nvidia.com>
On 12/18/24 13:00, Nicolin Chen wrote:
> This is a reverse search v.s. iommufd_viommu_find_dev, as drivers may want
> to convert a struct device pointer (physical) to its virtual device ID for
> an event injection to the user space VM.
>
> Again, this avoids exposing more core structures to the drivers, than the
> iommufd_viommu alone.
>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
> include/linux/iommufd.h | 8 ++++++++
> drivers/iommu/iommufd/driver.c | 20 ++++++++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> index b082676c9e43..ac1f1897d290 100644
> --- a/include/linux/iommufd.h
> +++ b/include/linux/iommufd.h
> @@ -190,6 +190,8 @@ struct iommufd_object *_iommufd_object_alloc(struct iommufd_ctx *ictx,
> enum iommufd_object_type type);
> struct device *iommufd_viommu_find_dev(struct iommufd_viommu *viommu,
> unsigned long vdev_id);
> +unsigned long iommufd_viommu_get_vdev_id(struct iommufd_viommu *viommu,
> + struct device *dev);
Hi Nicolin,
This series overall looks good to me. But I have a question that might
be irrelevant to this series itself.
The iommufd provides both IOMMUFD_OBJ_DEVICE and IOMMUFD_OBJ_VDEVICE
objects. What is the essential difference between these two from
userspace's perspective? And, which object ID should the IOMMU device
driver provide when reporting other events in the future?
Currently, the IOMMUFD uAPI reports IOMMUFD_OBJ_DEVICE in the page
fault message, and IOMMUFD_OBJ_VDEVICE (if I understand it correctly) in
the vIRQ message. It will be more future-proof if this could be defined
clearly.
Thanks,
baolu
next prev parent reply other threads:[~2024-12-19 2:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 5:00 [PATCH v3 00/14] iommufd: Add vIOMMU infrastructure (Part-3: vIRQ) Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 01/14] iommufd: Keep IOCTL list in an alphabetical order Nicolin Chen
2024-12-19 22:30 ` Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 02/14] iommufd/fault: Add an iommufd_fault_init() helper Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 03/14] iommufd/fault: Move iommufd_fault_iopf_handler() to header Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 04/14] iommufd: Abstract an iommufd_eventq from iommufd_fault Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 05/14] iommufd: Rename fault.c to eventq.c Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 06/14] iommufd: Add IOMMUFD_OBJ_VIRQ and IOMMUFD_CMD_VIRQ_ALLOC Nicolin Chen
2024-12-19 22:31 ` Nicolin Chen
2025-01-02 20:45 ` Jason Gunthorpe
2025-01-02 22:30 ` Nicolin Chen
2025-01-02 20:52 ` Jason Gunthorpe
2025-01-03 3:30 ` Nicolin Chen
2025-01-06 16:59 ` Jason Gunthorpe
2024-12-18 5:00 ` [PATCH v3 07/14] iommufd/viommu: Add iommufd_viommu_get_vdev_id helper Nicolin Chen
2024-12-19 2:05 ` Baolu Lu [this message]
2024-12-19 5:06 ` Nicolin Chen
2024-12-23 2:28 ` Baolu Lu
2024-12-23 19:29 ` Nicolin Chen
2025-01-02 20:29 ` Jason Gunthorpe
2025-01-03 1:19 ` Baolu Lu
2024-12-18 5:00 ` [PATCH v3 08/14] iommufd/viommu: Add iommufd_viommu_report_irq helper Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 09/14] iommufd/selftest: Require vdev_id when attaching to a nested domain Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 10/14] iommufd/selftest: Add IOMMU_TEST_OP_TRIGGER_VIRQ for vIRQ coverage Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 11/14] iommufd/selftest: Add IOMMU_VIRQ_ALLOC test coverage Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 12/14] Documentation: userspace-api: iommufd: Update FAULT and VIRQ Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 13/14] iommu/arm-smmu-v3: Introduce struct arm_smmu_vmaster Nicolin Chen
2024-12-18 5:00 ` [PATCH v3 14/14] iommu/arm-smmu-v3: Report IRQs that belong to devices attached to vIOMMU 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=56c65e50-5890-42af-85b7-85f8a1bf5cf5@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=ddutile@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--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 \
/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).