From: Jean-Philippe Brucker <firstname.lastname@example.org> To: Jacob Pan <email@example.com> Cc: "Tian, Kevin" <firstname.lastname@example.org>, "Raj, Ashok" <email@example.com>, Jean-Philippe Brucker <firstname.lastname@example.org>, "Lu, Baolu" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "Wu, Hao" <firstname.lastname@example.org> 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 <email@example.com> 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 elegant. > > 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, > > e.g. IOASID_SET_TYPE_MM > > IOASID_SET_TYPE_ANY > > 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 > > IOASID_SET_TYPE_ANY > > > > 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. Thanks, Jean _______________________________________________ iommu mailing list firstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent 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: 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=20200706103041.GA3214@myrica \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: IOASID set token' \ /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
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).