archive mirror
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <>
To: Jacob Pan <>
Cc: "Tian, Kevin" <>,
	"Raj, Ashok" <>,
	Jean-Philippe Brucker <>,
	"Lu, Baolu" <>,
	<>, "Wu, Hao" <>
Subject: Re: IOASID set token
Date: Mon, 6 Jul 2020 12:30:41 +0200	[thread overview]
Message-ID: <20200706103041.GA3214@myrica> (raw)
In-Reply-To: <20200702064825.20f9d2b1@jacob-builder>

Hi Jacob,

On Thu, Jul 02, 2020 at 06:48:25AM -0700, Jacob Pan wrote:
> Hi Jean,
> Just realized I should send this to your Linaro account instead of ARM.
> So Hi again :)
> On Wed, 1 Jul 2020 23:29:16 -0700
> Jacob Pan <> wrote:
> > Hi Jean,
> > 
> > Have a question for you on whether we can have a fixed token type for
> > ioasid_set.
> > 
> > Currently, ioasid_set has an arbitrary token. For VT-d vSVA usage, we
> > choose mm as ioasid_set token to identify PASIDs within a guest. We
> > have multiple in-kernel users of PASIDs such as VFIO, KVM, and VDCM.
> > When an IOASID set is created, there is not a good way to communicate
> > about the token choices. So we have to let VDCM and KVM *assume* mm
> > is used as token, then retrieve ioasid_set based on the token.
> > 
> > This assumption of "mm as token" is not a reliable SW architecture.

I don't see this as a problem. The token type is tied to the IOASID set,
so users that pass those IOASID sets to ioasid_find() can safely assume
that the returned pointer is an mm_struct. That said I'm not opposed to
consolidating the API with explicit types, it could definitely be more

> > So
> > we are thinking if we can have an explicit ioasid_set token type where
> > mm is used. After all, PASID and mm are closely related.
> > 
> > The code change might be the following:
> > 1. add a flag to indicate token type when ioasid_set is allocated,
> > 2. other users of the ioasid_set can query if an mm token exists based
> > on the flag IOASID_SET_TYPE_MM, then retrieve the ioasid_set.
> > 
> > Existing ioasid_set user can still use arbitrary token under the flag
> > 
> > Would this be an issue for ARM usage?

In my current implementation of auxiliary domains for Arm SMMU (which
might never be useful enough to go upstream) I don't even use a token for
the private IOASID set. However I still think we should leave the option
to use a type different than mm_struct as token for some IOASID sets
because device drivers (e.g. AMD kfd) may also want to dip into the IOASID
space and use their own token type.

For the moment, though, we could actually specialize the IOASID API to
only take an mm_struct as token. For example the functions exported by the
IOASID lib would be:

  ioasid_t ioasid_alloc_mm(set, min, max, struct mm_struct *mm)
  struct mm_struct *ioasid_find_mm(set, ioasid)

And ioasid_alloc(), ioasid_find(), etc would be internal to ioasid.c and
deal with IOASID_SET_TYPE_MM (or even be removed entirely for now). New
users that need different token types could then introduce their own
IOASID_SET_TYPE_* and use the lower-level functions.

iommu mailing list

  reply	other threads:[~2020-07-06 10:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  6:29 Jacob Pan
2020-07-02 13:48 ` Jacob Pan
2020-07-06 10:30   ` Jean-Philippe Brucker [this message]
2020-07-06 20:51     ` Jacob Pan
2020-07-07 10:07       ` Jean-Philippe Brucker
2020-07-07 15:38         ` Jacob Pan

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200706103041.GA3214@myrica \ \ \ \ \ \ \ \ \
    --subject='Re: IOASID set token' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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