From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH 2/9] iommu: Add device parameter to iopf handler
Date: Tue, 11 Jul 2023 22:46:01 -0700 [thread overview]
Message-ID: <20230711224601.5973ec3f@jacob-builder> (raw)
In-Reply-To: <4519fb58-9b56-3c99-48be-a70505571f4a@linux.intel.com>
Hi Baolu,
On Wed, 12 Jul 2023 10:16:11 +0800, Baolu Lu <baolu.lu@linux.intel.com>
wrote:
> On 2023/7/12 1:26, Jacob Pan wrote:
> > Hi BaoLu,
>
> Hi Jacob,
>
> >
> > On Tue, 11 Jul 2023 09:06:35 +0800, Lu Baolu<baolu.lu@linux.intel.com>
> > wrote:
> >
> >> Add the device parameter to the iopf handler so that it can know which
> >> device this fault was generated.
> >>
> >> This is necessary for use cases such as delivering IO page faults to
> >> user space. The IOMMUFD layer needs to be able to lookup the device id
> >> of a fault and route it together with the fault message to the user
> >> space.
> >>
> >> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com>
> >> ---
> >> include/linux/iommu.h | 1 +
> >> drivers/iommu/iommu-sva.h | 4 ++--
> >> drivers/iommu/io-pgfault.c | 2 +-
> >> drivers/iommu/iommu-sva.c | 2 +-
> >> 4 files changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >> index 0eb0fb852020..a00fb43b5e73 100644
> >> --- a/include/linux/iommu.h
> >> +++ b/include/linux/iommu.h
> >> @@ -249,6 +249,7 @@ struct iommu_domain {
> >> struct iommu_domain_geometry geometry;
> >> struct iommu_dma_cookie *iova_cookie;
> >> enum iommu_page_response_code (*iopf_handler)(struct
> >> iommu_fault *fault,
> >> + struct device
> >> *dev, void *data);
> >> void *fault_data;
> >> union {
> >> diff --git a/drivers/iommu/iommu-sva.h b/drivers/iommu/iommu-sva.h
> >> index 54946b5a7caf..c848661c4e20 100644
> >> --- a/drivers/iommu/iommu-sva.h
> >> +++ b/drivers/iommu/iommu-sva.h
> >> @@ -23,7 +23,7 @@ struct iopf_queue *iopf_queue_alloc(const char
> >> *name); void iopf_queue_free(struct iopf_queue *queue);
> >> int iopf_queue_discard_partial(struct iopf_queue *queue);
> >> enum iommu_page_response_code
> >> -iommu_sva_handle_iopf(struct iommu_fault *fault, void *data);
> >> +iommu_sva_handle_iopf(struct iommu_fault *fault, struct device *dev,
> >> void *data);
> >> #else /* CONFIG_IOMMU_SVA */
> >> static inline int iommu_queue_iopf(struct iommu_fault *fault, void
> >> *cookie) @@ -63,7 +63,7 @@ static inline int
> >> iopf_queue_discard_partial(struct iopf_queue *queue) }
> >>
> >> static inline enum iommu_page_response_code
> >> -iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
> >> +iommu_sva_handle_iopf(struct iommu_fault *fault, struct device *dev,
> >> void *data) {
> >> return IOMMU_PAGE_RESP_INVALID;
> >> }
> >> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> >> index e5b8b9110c13..fa604e1b5c5c 100644
> >> --- a/drivers/iommu/io-pgfault.c
> >> +++ b/drivers/iommu/io-pgfault.c
> >> @@ -88,7 +88,7 @@ static void iopf_handler(struct work_struct *work)
> >> * faults in the group if there is an error.
> >> */
> >> if (status == IOMMU_PAGE_RESP_SUCCESS)
> >> - status = domain->iopf_handler(&iopf->fault,
> >> + status = domain->iopf_handler(&iopf->fault,
> >> group->dev, domain->fault_data);
> >>
> >> if (!(iopf->fault.prm.flags &
> >> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> >> index 3ebd4b6586b3..14766a2b61af 100644
> >> --- a/drivers/iommu/iommu-sva.c
> >> +++ b/drivers/iommu/iommu-sva.c
> >> @@ -157,7 +157,7 @@ EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
> >> * I/O page fault handler for SVA
> >> */
> >> enum iommu_page_response_code
> >> -iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
> >> +iommu_sva_handle_iopf(struct iommu_fault *fault, struct device *dev,
> > dev has no use for sva handler, right? mark them __always_unused?
>
> My understanding is that __always_unused attribute in Linux kernel code
> marks a variable or function as unused. It implies that the compiler is
> free to optimize the variable or function away.
that is my understanding as well, I meant
iommu_sva_handle_iopf(struct iommu_fault *fault, struct device
__always_unused *dev,
I tested compile w/ and w/o __always_unused, seems no difference but it
makes the code clear that dev is not used here.
Thanks,
Jacob
next prev parent reply other threads:[~2023-07-12 5:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 1:06 [PATCH 0/9] iommu: Prepare to deliver page faults to user space Lu Baolu
2023-07-11 1:06 ` [PATCH 1/9] iommu: Move iommu fault data to linux/iommu.h Lu Baolu
2023-07-11 6:05 ` Tian, Kevin
2023-07-12 2:07 ` Baolu Lu
2023-07-12 9:33 ` Jean-Philippe Brucker
2023-07-13 3:22 ` Tian, Kevin
2023-07-13 3:48 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 2/9] iommu: Add device parameter to iopf handler Lu Baolu
2023-07-11 17:26 ` Jacob Pan
2023-07-12 2:16 ` Baolu Lu
2023-07-12 5:46 ` Jacob Pan [this message]
2023-07-11 1:06 ` [PATCH 3/9] iommu: Add common code to handle IO page faults Lu Baolu
2023-07-11 6:12 ` Tian, Kevin
2023-07-12 2:32 ` Baolu Lu
2023-07-12 9:45 ` Jean-Philippe Brucker
2023-07-13 4:02 ` Baolu Lu
2023-07-11 20:50 ` Jacob Pan
2023-07-12 2:37 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 4/9] iommu: Change the return value of dev_iommu_get() Lu Baolu
2023-07-11 21:05 ` Jacob Pan
2023-07-11 1:06 ` [PATCH 5/9] iommu: Make fault_param generic Lu Baolu
2023-07-11 6:14 ` Tian, Kevin
2023-07-12 2:43 ` Baolu Lu
2023-07-11 21:31 ` Jacob Pan
2023-07-12 3:02 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 6/9] iommu: Remove iommu_[un]register_device_fault_handler() Lu Baolu
2023-07-11 1:06 ` [PATCH 7/9] iommu: Add helper to set iopf handler for domain Lu Baolu
2023-07-11 1:06 ` [PATCH 8/9] iommu: Add iommu page fault cookie helpers Lu Baolu
2023-07-11 1:06 ` [PATCH 9/9] iommu: Use fault cookie to store iopf_param Lu Baolu
2023-07-11 6:26 ` Tian, Kevin
2023-07-12 3:09 ` Baolu Lu
2023-07-11 22:02 ` Jacob Pan
2023-07-12 3:13 ` Baolu Lu
2023-07-13 3:24 ` Tian, Kevin
2023-07-13 3:43 ` Baolu Lu
2023-07-13 8:01 ` Tian, Kevin
2023-07-14 2:49 ` Baolu Lu
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=20230711224601.5973ec3f@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.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).