From: "Tian, Kevin" <kevin.tian@intel.com>
To: "eric.auger@redhat.com" <eric.auger@redhat.com>,
Jason Gunthorpe <jgg@nvidia.com>,
"Alex Williamson (alex.williamson@redhat.com)"
<alex.williamson@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
David Gibson <david@gibson.dropbear.id.au>,
"Jason Wang" <jasowang@redhat.com>,
"parav@mellanox.com" <parav@mellanox.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Paolo Bonzini <pbonzini@redhat.com>,
Shenming Lu <lushenming@huawei.com>,
Joerg Roedel <joro@8bytes.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
"Jiang, Dave" <dave.jiang@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
"Kirti Wankhede" <kwankhede@nvidia.com>,
Robin Murphy <robin.murphy@arm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"David Woodhouse" <dwmw2@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
"Lu Baolu" <baolu.lu@linux.intel.com>
Subject: RE: [RFC v2] /dev/iommu uAPI proposal
Date: Tue, 10 Aug 2021 09:00:46 +0000 [thread overview]
Message-ID: <BN9PR11MB5433FC19698D3A86B63850128CF79@BN9PR11MB5433.namprd11.prod.outlook.com> (raw)
In-Reply-To: <cec41751-c300-40f2-a8d6-f4916fb4a34e@redhat.com>
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Tuesday, August 10, 2021 3:17 PM
>
> Hi Kevin,
>
> On 8/5/21 2:36 AM, Tian, Kevin wrote:
> >> From: Eric Auger <eric.auger@redhat.com>
> >> Sent: Wednesday, August 4, 2021 11:59 PM
> >>
> > [...]
> >>> 1.2. Attach Device to I/O address space
> >>> +++++++++++++++++++++++++++++++++++++++
> >>>
> >>> Device attach/bind is initiated through passthrough framework uAPI.
> >>>
> >>> Device attaching is allowed only after a device is successfully bound to
> >>> the IOMMU fd. User should provide a device cookie when binding the
> >>> device through VFIO uAPI. This cookie is used when the user queries
> >>> device capability/format, issues per-device iotlb invalidation and
> >>> receives per-device I/O page fault data via IOMMU fd.
> >>>
> >>> Successful binding puts the device into a security context which isolates
> >>> its DMA from the rest system. VFIO should not allow user to access the
> >> s/from the rest system/from the rest of the system
> >>> device before binding is completed. Similarly, VFIO should prevent the
> >>> user from unbinding the device before user access is withdrawn.
> >> With Intel scalable IOV, I understand you could assign an RID/PASID to
> >> one VM and another one to another VM (which is not the case for ARM).
> Is
> >> it a targetted use case?How would it be handled? Is it related to the
> >> sub-groups evoked hereafter?
> > Not related to sub-group. Each mdev is bound to the IOMMU fd
> respectively
> > with the defPASID which represents the mdev.
> But how does it work in term of security. The device (RID) is bound to
> an IOMMU fd. But then each SID/PASID may be working for a different VM.
> How do you detect this is safe as each SID can work safely for a
> different VM versus the ARM case where it is not possible.
PASID is managed by the parent driver, which knows which PASID to be
used given a mdev when later attaching it to an IOASID.
>
> 1.3 says
> "
>
> 1) A successful binding call for the first device in the group creates
> the security context for the entire group, by:
> "
> What does it mean for above scalable IOV use case?
>
This is a good question (as Alex raised) which needs more explanation
in next version:
https://lore.kernel.org/linux-iommu/20210712124150.2bf421d1.alex.williamson@redhat.com/
In general we need provide different helpers for binding pdev/mdev/
sw mdev. 1.3 in v2 describes the behavior for pdev via iommu_register_
device(). for mdev a new helper (e.g. iommu_register_device_pasid())
is required and then the IOMMU-API will also provide a pasid variation
for creating security context per pasid. sw mdev will also have its binding
helper to indicate no routing info required in ioasid attaching.
Thanks
Kevin
prev parent reply other threads:[~2021-08-10 9:00 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 7:48 [RFC v2] /dev/iommu uAPI proposal Tian, Kevin
2021-07-09 21:50 ` Alex Williamson
2021-07-12 1:22 ` Tian, Kevin
2021-07-12 18:41 ` Alex Williamson
2021-07-12 23:41 ` Tian, Kevin
2021-07-12 23:56 ` Tian, Kevin
2021-07-13 12:55 ` Jason Gunthorpe
2021-07-13 16:26 ` Alex Williamson
2021-07-13 16:32 ` Jason Gunthorpe
2021-07-13 22:48 ` Tian, Kevin
2021-07-13 23:02 ` Jason Gunthorpe
2021-07-13 23:20 ` Tian, Kevin
2021-07-13 23:22 ` Jason Gunthorpe
2021-07-13 23:24 ` Tian, Kevin
2021-07-15 3:20 ` Shenming Lu
2021-07-15 3:55 ` Tian, Kevin
2021-07-15 6:29 ` Shenming Lu
2021-07-15 6:49 ` Tian, Kevin
2021-07-15 8:14 ` Shenming Lu
2021-07-15 12:48 ` Jason Gunthorpe
2021-07-15 13:57 ` Raj, Ashok
2021-07-15 15:23 ` Jason Gunthorpe
2021-07-15 16:21 ` Raj, Ashok
2021-07-15 17:18 ` Jason Gunthorpe
2021-07-15 17:48 ` Raj, Ashok
2021-07-15 17:53 ` Jason Gunthorpe
2021-07-15 18:05 ` Raj, Ashok
2021-07-15 18:13 ` Jason Gunthorpe
2021-07-16 1:20 ` Tian, Kevin
2021-07-16 12:20 ` Shenming Lu
2021-07-21 2:13 ` Tian, Kevin
2021-07-22 16:30 ` Jason Gunthorpe
2021-07-16 18:30 ` Jason Gunthorpe
2021-07-21 2:11 ` Tian, Kevin
2021-07-26 4:50 ` David Gibson
2021-07-28 4:04 ` Tian, Kevin
2021-08-03 1:50 ` David Gibson
2021-08-03 3:19 ` Tian, Kevin
2021-08-06 4:45 ` David Gibson
2021-08-06 12:32 ` Jason Gunthorpe
2021-08-10 6:10 ` David Gibson
2021-08-09 8:34 ` Tian, Kevin
2021-08-10 4:47 ` David Gibson
2021-08-10 6:04 ` Tian, Kevin
2021-07-30 14:51 ` Jason Gunthorpe
2021-08-02 2:49 ` Tian, Kevin
2021-08-04 14:04 ` Jason Gunthorpe
2021-08-04 22:59 ` Tian, Kevin
2021-08-05 11:27 ` Jason Gunthorpe
2021-08-05 22:44 ` Tian, Kevin
2021-08-06 4:47 ` David Gibson
2021-08-03 1:58 ` David Gibson
2021-08-04 14:07 ` Jason Gunthorpe
2021-08-06 4:24 ` David Gibson
2021-07-26 8:14 ` Jean-Philippe Brucker
2021-07-28 4:05 ` Tian, Kevin
2021-08-04 15:59 ` Eric Auger
2021-08-05 0:36 ` Tian, Kevin
2021-08-10 7:17 ` Eric Auger
2021-08-10 9:00 ` Tian, Kevin [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=BN9PR11MB5433FC19698D3A86B63850128CF79@BN9PR11MB5433.namprd11.prod.outlook.com \
--to=kevin.tian@intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dave.jiang@intel.com \
--cc=david@gibson.dropbear.id.au \
--cc=dwmw2@infradead.org \
--cc=eric.auger@redhat.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metux.net \
--cc=lushenming@huawei.com \
--cc=parav@mellanox.com \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=yi.l.liu@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 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).