From: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
To: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Robin Murphy <Robin.Murphy-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 1/8] iommu: Add I/O ASID allocator
Date: Tue, 18 Jun 2019 15:22:20 +0100 [thread overview]
Message-ID: <13e19d8c-8918-a3bb-f398-2ac41c71d307@arm.com> (raw)
In-Reply-To: <20190611111333.425ce809@jacob-builder>
On 11/06/2019 19:13, Jacob Pan wrote:
>>>> +/**
>>>> + * ioasid_find - Find IOASID data
>>>> + * @set: the IOASID set
>>>> + * @ioasid: the IOASID to find
>>>> + * @getter: function to call on the found object
>>>> + *
>>>> + * The optional getter function allows to take a reference to the
>>>> found object
>>>> + * under the rcu lock. The function can also check if the object
>>>> is still valid:
>>>> + * if @getter returns false, then the object is invalid and NULL
>>>> is returned.
>>>> + *
>>>> + * If the IOASID has been allocated for this set, return the
>>>> private pointer
>>>> + * passed to ioasid_alloc. Private data can be NULL if not set.
>>>> Return an error
>>>> + * if the IOASID is not found or does not belong to the set.
>>>
>>> Perhaps should make it clear that @set can be null.
>>
>> Indeed. But I'm not sure allowing @set to be NULL is such a good idea,
>> because the data type associated to an ioasid depends on its set. For
>> example SVA will put an mm_struct in there, and auxiliary domains use
>> some structure private to the IOMMU domain.
>>
> I am not sure we need to count on @set to decipher data type. Whoever
> does the allocation and owns the IOASID should knows its own data type.
> My thought was that @set is only used to group IDs, permission check
> etc.
>
>> Jacob, could me make @set mandatory, or do you see a use for a global
>> search? If @set is NULL, then callers can check if the return pointer
>> is NULL, but will run into trouble if they try to dereference it.
>>
> A global search use case can be for PRQ. IOMMU driver gets a IOASID
> (first interrupt then retrieve from a queue), it has no idea which
> @set it belongs to. But the data types are the same for all IOASIDs
> used by the IOMMU.
They aren't when we use a generic SVA handler. Following a call to
iommu_sva_bind_device(), iommu-sva.c allocates an IOASID and store an
mm_struct. If auxiliary domains are also enabled for the device,
following a call to iommu_aux_attach_device() the IOMMU driver allocates
an IOASID and stores some private object.
Now for example the IOMMU driver receives a PPR and calls ioasid_find()
with @set = NULL. ioasid_find() may return either an mm_struct or a
private object, and the driver cannot know which it is so the returned
value is unusable.
Thanks,
Jean
next prev parent reply other threads:[~2019-06-18 14:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 18:47 [PATCH 0/8] iommu: Add auxiliary domain and PASID support to Arm SMMUv3 Jean-Philippe Brucker
[not found] ` <20190610184714.6786-1-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2019-06-10 18:47 ` [PATCH 1/8] iommu: Add I/O ASID allocator Jean-Philippe Brucker
2019-06-11 9:36 ` Jonathan Cameron
2019-06-11 14:35 ` Jean-Philippe Brucker
[not found] ` <62d1f310-0cba-4d55-0f16-68bba3c64927-5wv7dgnIgG8@public.gmane.org>
2019-06-11 18:13 ` Jacob Pan
2019-06-18 14:22 ` Jean-Philippe Brucker [this message]
[not found] ` <13e19d8c-8918-a3bb-f398-2ac41c71d307-5wv7dgnIgG8@public.gmane.org>
2019-06-18 17:05 ` Jacob Pan
2019-06-19 14:26 ` Jean-Philippe Brucker
2019-06-11 12:26 ` Jacob Pan
2019-06-11 14:37 ` Jean-Philippe Brucker
[not found] ` <95292b47-4cf4-5fd9-b096-1cb016e2264f-5wv7dgnIgG8@public.gmane.org>
2019-06-11 17:10 ` Jacob Pan
2019-06-12 11:30 ` Jean-Philippe Brucker
2019-06-10 18:47 ` [PATCH 2/8] dt-bindings: document PASID property for IOMMU masters Jean-Philippe Brucker
2019-07-08 7:58 ` Auger Eric
2019-06-10 18:47 ` [PATCH 3/8] iommu/arm-smmu-v3: Support platform SSID Jean-Philippe Brucker
2019-06-11 9:42 ` Jonathan Cameron
2019-06-11 14:35 ` Jean-Philippe Brucker
2019-06-18 18:08 ` Will Deacon
2019-06-19 11:53 ` Jean-Philippe Brucker
2019-07-08 7:58 ` Auger Eric
2019-09-19 14:51 ` Jean-Philippe Brucker
2019-06-10 18:47 ` [PATCH 4/8] iommu/arm-smmu-v3: Add support for Substream IDs Jean-Philippe Brucker
2019-06-11 10:19 ` Jonathan Cameron
2019-06-11 14:35 ` Jean-Philippe Brucker
[not found] ` <20190610184714.6786-5-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2019-06-26 18:00 ` Will Deacon
2019-07-04 9:33 ` Jean-Philippe Brucker
2019-09-19 14:57 ` Jean-Philippe Brucker
2019-07-08 15:31 ` Auger Eric
[not found] ` <af286d72-97d7-d106-40a8-edfcbe563c98-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-09-19 15:01 ` Jean-Philippe Brucker
2019-06-10 18:47 ` [PATCH 5/8] iommu/arm-smmu-v3: Add second level of context descriptor table Jean-Philippe Brucker
2019-06-11 10:24 ` Jonathan Cameron
2019-07-08 15:13 ` Auger Eric
2019-09-19 15:05 ` Jean-Philippe Brucker
2019-06-10 18:47 ` [PATCH 6/8] iommu/arm-smmu-v3: Support auxiliary domains Jean-Philippe Brucker
2019-06-26 17:59 ` Will Deacon
2019-07-05 16:29 ` Jean-Philippe Brucker
2019-09-19 15:06 ` Jean-Philippe Brucker
2019-06-10 18:47 ` [PATCH 7/8] iommu/arm-smmu-v3: Improve add_device() error handling Jean-Philippe Brucker
2019-07-08 7:58 ` Auger Eric
2019-06-10 18:47 ` [PATCH 8/8] iommu/arm-smmu-v3: Add support for PCI PASID Jean-Philippe Brucker
2019-06-11 10:45 ` Jonathan Cameron
2019-06-11 14:35 ` Jean-Philippe Brucker
2019-07-08 7:58 ` Auger Eric
2019-09-19 15:10 ` Jean-Philippe Brucker
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=13e19d8c-8918-a3bb-f398-2ac41c71d307@arm.com \
--to=jean-philippe.brucker-5wv7dgnigg8@public.gmane.org \
--cc=Mark.Rutland-5wv7dgnIgG8@public.gmane.org \
--cc=Robin.Murphy-5wv7dgnIgG8@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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).