From: "Raj, Ashok" <ashok.raj@intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>,
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,
baolu.lu@linux.intel.com, alex.williamson@redhat.com,
Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH 1/1] iommu: Bind process address spaces to devices
Date: Thu, 28 Feb 2019 14:04:49 -0800 [thread overview]
Message-ID: <20190228220449.GA12682@araj-mobl1.jf.intel.com> (raw)
In-Reply-To: <20190228131549.6c0e5fad@jacob-builder>
On Thu, Feb 28, 2019 at 01:15:49PM -0800, Jacob Pan wrote:
> On Thu, 28 Feb 2019 15:09:50 +0100
> Joerg Roedel <joro@8bytes.org> wrote:
>
> > 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?
> >
> I will delegate this to Ashok.
Supervisor PASID is still required for some kernel clients. Some of our
IB folks had asked for it. Current implementation uses init_mm, but
we know this is dangerous. Plus since the kernel has no support for
mmu_notifiers for kernel memory we were not able to invalidate
device tlb after memory was freed.
Suppose we could just build regular page-tables much like how the map/unmap
does today, but bind it with a Supervisor PASID. This way we don't open
up the kimono to the device, but only open select portions on request.
we haven't spent enough time on it lately, but will focus once the core
pieces are completed for the baseline support for Scalable mode.
prev parent reply other threads:[~2019-02-28 22:04 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
2019-02-28 21:15 ` Jacob Pan
2019-02-28 22:04 ` Raj, Ashok [this message]
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=20190228220449.GA12682@araj-mobl1.jf.intel.com \
--to=ashok.raj@intel.com \
--cc=alex.williamson@redhat.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=joro@8bytes.org \
--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).