From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Vasant Hegde <vasant.hegde@amd.com>,
Baolu Lu <baolu.lu@linux.intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"joro@8bytes.org" <joro@8bytes.org>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging()
Date: Tue, 13 Aug 2024 13:20:44 -0300 [thread overview]
Message-ID: <20240813162044.GI1985367@ziepe.ca> (raw)
In-Reply-To: <BN9PR11MB52765C37F5401E9AA7113D748C862@BN9PR11MB5276.namprd11.prod.outlook.com>
On Tue, Aug 13, 2024 at 09:40:32AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@ziepe.ca>
> > Sent: Thursday, August 8, 2024 2:30 AM
> >
> > On Wed, Aug 07, 2024 at 10:22:00PM +0530, Vasant Hegde wrote:
> > > > Needs more words, maybe even two flags?
> > > >
> > > > @IOMMU_HWPT_ALLOC_DEV_PASID: When the domain is used on a
> > device,
> > > > with no PASID, the device will support later attaching a PASID as
> > > > well. Some HW requires a specific domain format on the device to
> > > > allow PASID to work.
> > >
> > > I will add this.
> > >
> > > > @IOMMU_HWPT_ALLOC_PASID: The domain can be used as a PASID.
> > The
> > > > domain attached to the device must have also been allocated with
> > > > IOMMU_HWPT_ALLOC_DEV_PASID.
> > >
> > > Why do we need this flag? Previous one is already allocated PASID capable
> > > domain. Is this similar to SVA domain?
> >
> > IOMMU_HWPT_ALLOC_DEV_PASID is the flag you specify to allocate the
> > domain you will attach to the RID
> >
> > IOMMU_HWPT_ALLOC_PASID is the flag you specify if you intend to attach
> > this domain to a PASID
> >
> > They are actually different operations from a user perspective. Today
> > every iommu driver implements them with the same logic..
> >
> > So I thought perhaps they should be seperate, at least if we get some
> > really crazy HW down the road the uAPI will still work. uAPI is a bit
> > more tricky because you can't change it.
> >
>
> I'm not sure it's necessary to push this burden to all existing IOMMUs
> which don't have such requirement.
If we are making a common uAPI then we need to have all the HW act the
same. No implicit behaviors that people accidently rely on.
So if we say you need flags before domains can be used with PASID then
the core code must check those flags for all HW even if it is a
driver-NOP.
So what are the flags you want?
Flags = 0 means the domain cannot be attached to a PASID
Flags = 0 means the domain cannot be attached to the RID while PASID
is in use
The core code should enforce this rule always.
Above that we minimally need
Flags = IOMMU_HWPT_ALLOC_PASID allows the domain to be attached to a
PASID
And you need to decide if the RID usage is bundled with the above as
well.
> Can we simplify it by just supporting one flag and then incrementally
> add another one when a future demand comes and advocate such
> new requirement by GET_HW_INFO?
Well you end up not supporting any special cases that would need
it. It is uAPI so it is good to always be mindful that things are well
defined and clear.
If you want one flag then it still has to do both behaviors and you
still have to describe and enforce both behaviors. So I don't know
there is a lot of savings, or that it is clearer.
I hope nobody ever needs two flags, that would be terrible HW..
Jason
next prev parent reply other threads:[~2024-08-13 16:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 14:45 [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging() Vasant Hegde
2024-08-02 0:44 ` Baolu Lu
2024-08-02 5:53 ` Vasant Hegde
2024-08-06 12:34 ` Jason Gunthorpe
2024-08-06 14:41 ` Vasant Hegde
2024-08-06 17:32 ` Jason Gunthorpe
2024-08-07 5:49 ` Baolu Lu
2024-08-07 9:32 ` Vasant Hegde
2024-08-07 12:33 ` Jason Gunthorpe
2024-08-07 9:30 ` Vasant Hegde
2024-08-07 13:59 ` Jason Gunthorpe
2024-08-07 16:52 ` Vasant Hegde
2024-08-07 18:29 ` Jason Gunthorpe
2024-08-08 1:16 ` Jason Gunthorpe
2024-08-08 13:08 ` Jason Gunthorpe
2024-08-09 6:43 ` Vasant Hegde
2024-08-09 13:44 ` Jason Gunthorpe
2024-08-12 9:21 ` Vasant Hegde
2024-08-13 16:22 ` Jason Gunthorpe
2024-08-14 10:54 ` Vasant Hegde
2024-08-09 5:36 ` Vasant Hegde
2024-08-12 12:07 ` Yi Liu
2024-08-13 9:40 ` Tian, Kevin
2024-08-13 16:20 ` Jason Gunthorpe [this message]
2024-08-14 2:38 ` Tian, Kevin
2024-08-14 22:40 ` Jason Gunthorpe
2024-08-15 3:28 ` Vasant Hegde
2024-08-15 4:58 ` Yi Liu
2024-08-15 13:06 ` Jason Gunthorpe
2024-08-16 11:59 ` Yi Liu
2024-08-15 4:59 ` Baolu Lu
2024-08-15 13:47 ` Jason Gunthorpe
2024-08-16 8:17 ` Vasant Hegde
2024-08-16 12:01 ` Yi Liu
2024-08-16 18:37 ` Jason Gunthorpe
2024-08-19 8:27 ` Vasant Hegde
2024-08-19 17:52 ` Jason Gunthorpe
2024-08-20 8:18 ` Vasant Hegde
2024-08-15 13:05 ` Jason Gunthorpe
2024-08-12 12:01 ` Yi Liu
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=20240813162044.GI1985367@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@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 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.