All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	"Raj, Ashok" <ashok.raj@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"Lu, Baolu" <baolu.lu@intel.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>, "Wu, Hao" <hao.wu@intel.com>
Subject: IOASID set token
Date: Wed, 1 Jul 2020 23:29:16 -0700	[thread overview]
Message-ID: <20200701232916.38fd7908@jacob-builder> (raw)

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

Thanks,

Jacob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

             reply	other threads:[~2020-07-02  6:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  6:29 Jacob Pan [this message]
2020-07-02 13:48 ` IOASID set token Jacob Pan
2020-07-06 10:30   ` Jean-Philippe Brucker
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=20200701232916.38fd7908@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@intel.com \
    --cc=hao.wu@intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@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.