From: "'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'" <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: "Tian, Kevin" <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jean-Philippe Brucker
<jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>,
"gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org"
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
"will.deacon-5wv7dgnIgG8@public.gmane.org"
<will.deacon-5wv7dgnIgG8@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
"christian.koenig-5C7GfCeVMHo@public.gmane.org"
<christian.koenig-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3
Date: Fri, 7 Dec 2018 11:29:26 +0100
Message-ID: <20181207102926.GM16835@8bytes.org> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19BE689B8-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi,
On Mon, Nov 26, 2018 at 07:29:45AM +0000, Tian, Kevin wrote:
> btw Baolu just reminded me one thing which is worthy of noting here.
> 'primary' vs. 'aux' concept makes sense only when we look from a device
> p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded
> cross devices. every domain must be explicitly attached to other devices
> (instead of implicitly attached being above example), and new primary/aux
> attribute on another device will be decided at attach time.
Okay, so after all the discussions we had I learned a few more things
about the scalable mode feature and thought a bit longer about how to
best support it in the IOMMU-API.
The concept of sub-domains I initially proposed certainly makes no
sense, but scalable-mode specific attach/detach functions do. So instead
of a sub-domain mode, I'd like to propose device-feature sets.
The posted patch-set already includes this as device-attributes, but I
don't like this naming as we are really talking about additional
feature sets of a device. So how about we introduce this:
enum iommu_dev_features {
/* ... */
IOMMU_DEV_FEAT_AUX,
IOMMU_DEV_FEAT_SVA,
/* ... */
};
/* Check if a device supports a given feature of the IOMMU-API */
bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features *feat);
/*
* Only works if iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
* returns true
*
* Also, as long as domains are attached to a device through
* this interface, any trys to call iommu_attach_device() should
* fail (iommu_detach_device() can't fail, so we fail on the
* tryint to re-attach). This should make us safe against a
* device being attached to a guest as a whole while there are
* still pasid users on it (aux and sva).
*/
int iommu_aux_attach_device(struct iommu_domain *domain,
struct device *dev);
int iommu_aux_detach_device(struct iommu_domain *domain,
struct device *dev);
/*
* I know we are targeting a system-wide pasid-space, so that
* the pasid would be the same for one domain on all devices,
* let's just keep the option open to have different
* pasid-spaces in one system. Also this way we can use it to
* check whether the domain is attached to this device at all.
*
* returns pasid or <0 if domain has no pasid on that device.
*/
int iommu_aux_get_pasid(struct iommu_domain *domain,
struct device *dev);
/* So we need a iommu_aux_detach_all()? */
This concept can also be easily extended for supporting SVA in parallel
on the same device, with the same constraints regarding the behavior of
iommu_attach_device()/iommu_detach_device().
So what do you think about that approach?
Regards,
Joerg
next prev parent reply index
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 18:11 Jean-Philippe Brucker
[not found] ` <20181019181158.2395-1-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2018-10-19 18:11 ` [RFC PATCH 1/6] iommu: Adapt attach/detach_dev() for auxiliary domains Jean-Philippe Brucker
[not found] ` <20181019181158.2395-2-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2018-10-22 2:32 ` Lu Baolu
2018-10-19 18:11 ` [RFC PATCH 2/6] drivers core: Add I/O ASID allocator Jean-Philippe Brucker
[not found] ` <20181019181158.2395-3-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2018-10-22 4:49 ` Lu Baolu
[not found] ` <9c6cd6c1-3569-4251-8344-fc9df0e743bc-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-10-22 10:22 ` Raj, Ashok
[not found] ` <20181022102254.GA25399-7RUrO8UaCDyr4tA6zuQqW9h3ngVCH38I@public.gmane.org>
2018-10-23 6:56 ` Lu Baolu
[not found] ` <02006e4f-2acf-6ff8-b695-c54c99509b46-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-10-23 22:13 ` Tian, Kevin
2018-11-07 4:53 ` Lu Baolu
[not found] ` <fb2bd5fe-5742-fcd8-b8f0-1885040e8d4f-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-11-08 18:51 ` Jean-Philippe Brucker
2018-11-12 14:40 ` Joerg Roedel
[not found] ` <20181112144039.GA25808-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-21 11:16 ` Jean-Philippe Brucker
[not found] ` <8f17757a-c657-aab9-a6a0-fb0cc9c610a8-5wv7dgnIgG8@public.gmane.org>
2018-11-21 19:10 ` Koenig, Christian
[not found] ` <62f05552-df46-6e12-10ed-820429dfda59-5C7GfCeVMHo@public.gmane.org>
2018-11-22 6:59 ` Tian, Kevin
2018-11-22 8:38 ` Joerg Roedel
2018-11-22 8:44 ` Joerg Roedel
[not found] ` <20181122084429.GB1586-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-22 11:17 ` Jean-Philippe Brucker
2018-10-19 18:11 ` [RFC PATCH 3/6] iommu/sva: Use external PASID allocator Jean-Philippe Brucker
2018-10-19 18:11 ` [RFC PATCH 4/6] iommu/sva: Support AUXD feature Jean-Philippe Brucker
2018-10-19 18:11 ` [RFC PATCH 5/6] iommu/arm-smmu-v3: Implement detach_dev op Jean-Philippe Brucker
2018-10-19 18:11 ` [RFC PATCH 6/6] iommu/arm-smmu-v3: Add support for auxiliary domains Jean-Philippe Brucker
2018-10-20 3:36 ` [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3 Xu Zaibo
2018-10-22 6:53 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE0E176-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-10-22 11:50 ` Robin Murphy
[not found] ` <11f88122-afd3-a34c-3cd4-db681bf5498b-5wv7dgnIgG8@public.gmane.org>
2018-10-22 15:35 ` Jordan Crouse
2018-10-22 18:01 ` Jean-Philippe Brucker
2018-11-06 16:25 ` joro-zLv9SwRftAIdnm+yROfE0A
[not found] ` <20181106162539.4gmkvg57mja3bn7k-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-07 3:40 ` Lu Baolu
[not found] ` <e22e3631-2ecb-664d-5666-8e0f865dec83-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-11-07 16:43 ` joro-zLv9SwRftAIdnm+yROfE0A
[not found] ` <20181107164323.GA19831-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-07 17:23 ` Alex Williamson
2018-11-21 4:40 ` Lu Baolu
[not found] ` <758bb120-5bc0-1e2d-ccd0-9be0bcc5d8bc-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-11-23 11:21 ` joro-zLv9SwRftAIdnm+yROfE0A
[not found] ` <20181123112125.GF1586-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-25 6:51 ` Lu Baolu
2018-11-26 3:01 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE68777@SHSMSX101.ccr.corp.intel.com>
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE68777-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-11-26 7:29 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE689B8-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-12-07 10:29 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org' [this message]
[not found] ` <20181207102926.GM16835-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-12-10 2:06 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE95394-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-12-10 8:57 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
[not found] ` <20181210085745.GN16835-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-12-11 18:34 ` Jean-Philippe Brucker
[not found] ` <4be63d12-fa1c-b180-761b-5e8ceed58545-5wv7dgnIgG8@public.gmane.org>
2018-12-12 9:22 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
2018-12-12 9:31 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE9D6CA-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-12-12 9:54 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
[not found] ` <20181212095403.GU16835-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-12-12 10:03 ` Tian, Kevin
2018-12-10 2:57 ` Lu Baolu
[not found] ` <bf1ee4a3-6d3f-e0db-a02a-1db819843a60-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-12-10 8:59 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
2018-12-11 13:35 ` Jean-Philippe Brucker
[not found] ` <fc173d9f-57e2-dd87-95d0-1c615f2e14e3-5wv7dgnIgG8@public.gmane.org>
2018-12-12 9:29 ` 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'
2018-11-08 18:29 ` Jean-Philippe Brucker
[not found] ` <42949d93-e22c-dd4d-cd49-46efc0b73cdb-5wv7dgnIgG8@public.gmane.org>
2018-11-12 14:55 ` joro-zLv9SwRftAIdnm+yROfE0A
[not found] ` <20181112145541.GB25808-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-21 19:05 ` Jean-Philippe Brucker
[not found] ` <5dcf9238-62b2-8df6-b378-183ee09c5951-5wv7dgnIgG8@public.gmane.org>
2018-11-23 12:50 ` joro-zLv9SwRftAIdnm+yROfE0A
2018-11-22 8:39 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19BE5A7A7-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-11-23 12:14 ` joro-zLv9SwRftAIdnm+yROfE0A
2018-10-22 10:07 ` Raj, Ashok
[not found] ` <20181021194426.GA11201-7RUrO8UaCDyr4tA6zuQqW9h3ngVCH38I@public.gmane.org>
2018-10-22 16:03 ` Jean-Philippe Brucker
[not found] ` <d45c5222-68e9-1d6e-730b-bb8dbc060586-5wv7dgnIgG8@public.gmane.org>
2018-10-23 17:16 ` Raj, Ashok
[not found] ` <1540314963.21962.20.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-23 22:08 ` Tian, Kevin
2018-10-26 3:00 ` Lu Baolu
2018-10-22 16:48 ` Jordan Crouse
[not found] ` <20181022164834.GH26762-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
2018-11-02 3:19 ` Lu Baolu
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=20181207102926.GM16835@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org \
--cc=kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@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
IOMMU Archive on lore.kernel.org
Archives are clonable:
git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \
iommu@lists.linux-foundation.org
public-inbox-index linux-iommu
Example config snippet for mirrors
Newsgroup available over NNTP:
nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git