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 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.