iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	christian.koenig@amd.com, kevin.tian@intel.com,
	ashok.raj@intel.com, baolu.lu@linux.intel.com,
	alex.williamson@redhat.com
Subject: Re: [PATCH 1/1] iommu: Bind process address spaces to devices
Date: Thu, 28 Feb 2019 15:09:50 +0100	[thread overview]
Message-ID: <20190228140950.GD1594@8bytes.org> (raw)
In-Reply-To: <20190227134129.51ad42ac@jacob-builder>

Hi Jacob,

On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote:
> On Tue, 26 Feb 2019 12:17:43 +0100
> Joerg Roedel <joro@8bytes.org> wrote:

> Just trying to understand how to use this API.
> So if we bind the same mm to two different devices, we should get two
> different iommu_sva handle, right?
> I think intel-svm still needs a flag argument for supervisor pasid etc.
> Other than that, I think both interface should work for vt-d.

I second Jean's question here, is supervisor pasid still needed with
scalable mode? What is the use-case and which mm_struct will be used for
supervisor accesses?

> Another question is that for nested SVA, we will need to bind guest mm.
> Do you think we should try to reuse this or have it separate? I am
> working on a separate API for now.

I think a separate API makes more sense. It could be somehow fit into
this as well, but having it separate is cleaner. And we already have
separate API for aux-domains, so this would be just another extension of
the IOMMU-API for using PASIDs.


> > 	int iommu_sva_get_pasid(struct iommu_sva *handle);
> If multiple bind to the same mm gets multiple handles, this API should
> retrieve the same pasid for different handle?

It can return the same handle if we store the pasid in the mm_struct,
for example ...
> Just curious why making the handle private instead of returning the
> pasid value in the handle?

... which is also the reason why I prefer the accessor function, it
allows to have the pasid not in the iommu_sva handle, but to retrieve it
from somewhere else (like the mm_struct).

Regards,

	Joerg

  parent reply	other threads:[~2019-02-28 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20 14:27 [PATCH 0/1] IOMMU SVA device driver interface Jean-Philippe Brucker
2019-02-20 14:27 ` [PATCH 1/1] iommu: Bind process address spaces to devices Jean-Philippe Brucker
2019-02-26 11:17   ` Joerg Roedel
2019-02-26 12:49     ` Jean-Philippe Brucker
2019-02-26 13:02       ` Joerg Roedel
2019-02-27 21:41     ` Jacob Pan
2019-02-28  1:10       ` Tian, Kevin
2019-02-28 18:53         ` Jacob Pan
2019-02-28 12:19       ` Jean-Philippe Brucker
2019-02-28 18:32         ` Jacob Pan
2019-02-28 14:09       ` Joerg Roedel [this message]
2019-02-28 21:15         ` Jacob Pan
2019-02-28 22:04           ` Raj, Ashok

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=20190228140950.GD1594@8bytes.org \
    --to=joro@8bytes.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).