From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"Jiang, Dave" <dave.jiang@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
David Woodhouse <dwmw2@infradead.org>,
Jason Wang <jasowang@redhat.com>,
"Alex Williamson \(alex.williamson@redhat.com\)"
<alex.williamson@redhat.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Shenming Lu <lushenming@huawei.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Paolo Bonzini <pbonzini@redhat.com>,
"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>,
David Gibson <david@gibson.dropbear.id.au>,
Robin Murphy <robin.murphy@arm.com>,
"parav@mellanox.com" <parav@mellanox.com>
Subject: Re: [RFC v2] /dev/iommu uAPI proposal
Date: Thu, 22 Jul 2021 13:30:38 -0300 [thread overview]
Message-ID: <20210722163038.GM1117491@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB54332CA3CF19835A7B2742688CE39@BN9PR11MB5433.namprd11.prod.outlook.com>
On Wed, Jul 21, 2021 at 02:13:23AM +0000, Tian, Kevin wrote:
> > From: Shenming Lu
> > Sent: Friday, July 16, 2021 8:20 PM
> >
> > On 2021/7/16 9:20, Tian, Kevin wrote:
> > > To summarize, for vIOMMU we can work with the spec owner to
> > > define a proper interface to feedback such restriction into the guest
> > > if necessary. For the kernel part, it's clear that IOMMU fd should
> > > disallow two devices attached to a single [RID] or [RID, PASID] slot
> > > in the first place.
> > >
> > > Then the next question is how to communicate such restriction
> > > to the userspace. It sounds like a group, but different in concept.
> > > An iommu group describes the minimal isolation boundary thus all
> > > devices in the group can be only assigned to a single user. But this
> > > case is opposite - the two mdevs (both support ENQCMD submission)
> > > with the same parent have problem when assigned to a single VM
> > > (in this case vPASID is vm-wide translated thus a same pPASID will be
> > > used cross both mdevs) while they instead work pretty well when
> > > assigned to different VMs (completely different vPASID spaces thus
> > > different pPASIDs).
> > >
> > > One thought is to have vfio device driver deal with it. In this proposal
> > > it is the vfio device driver to define the PASID virtualization policy and
> > > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands
> > > the restriction thus could just hide the vPASID capability when the user
> > > calls GET_INFO on the 2nd mdev in above scenario. In this way the
> > > user even doesn't need to know such restriction at all and both mdevs
> > > can be assigned to a single VM w/o any problem.
> > >
> >
> > The restriction only probably happens when two mdevs are assigned to one
> > VM,
> > how could the vfio device driver get to know this info to accurately hide
> > the vPASID capability for the 2nd mdev when VFIO_DEVICE_GET_INFO?
> > There is no
> > need to do this in other cases.
> >
>
> I suppose the driver can detect it via whether two mdevs are opened by a
> single process.
Just have the kernel some ID for the PASID numberspace - devices with
the same ID have to be represented as a single RID.
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Shenming Lu <lushenming@huawei.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Jason Wang <jasowang@redhat.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
"Jiang, Dave" <dave.jiang@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>,
"parav@mellanox.com" <parav@mellanox.com>,
"Alex Williamson (alex.williamson@redhat.com)"
<alex.williamson@redhat.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
David Gibson <david@gibson.dropbear.id.au>,
Robin Murphy <robin.murphy@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Paolo Bonzini <pbonzini@redhat.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC v2] /dev/iommu uAPI proposal
Date: Thu, 22 Jul 2021 13:30:38 -0300 [thread overview]
Message-ID: <20210722163038.GM1117491@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB54332CA3CF19835A7B2742688CE39@BN9PR11MB5433.namprd11.prod.outlook.com>
On Wed, Jul 21, 2021 at 02:13:23AM +0000, Tian, Kevin wrote:
> > From: Shenming Lu
> > Sent: Friday, July 16, 2021 8:20 PM
> >
> > On 2021/7/16 9:20, Tian, Kevin wrote:
> > > To summarize, for vIOMMU we can work with the spec owner to
> > > define a proper interface to feedback such restriction into the guest
> > > if necessary. For the kernel part, it's clear that IOMMU fd should
> > > disallow two devices attached to a single [RID] or [RID, PASID] slot
> > > in the first place.
> > >
> > > Then the next question is how to communicate such restriction
> > > to the userspace. It sounds like a group, but different in concept.
> > > An iommu group describes the minimal isolation boundary thus all
> > > devices in the group can be only assigned to a single user. But this
> > > case is opposite - the two mdevs (both support ENQCMD submission)
> > > with the same parent have problem when assigned to a single VM
> > > (in this case vPASID is vm-wide translated thus a same pPASID will be
> > > used cross both mdevs) while they instead work pretty well when
> > > assigned to different VMs (completely different vPASID spaces thus
> > > different pPASIDs).
> > >
> > > One thought is to have vfio device driver deal with it. In this proposal
> > > it is the vfio device driver to define the PASID virtualization policy and
> > > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands
> > > the restriction thus could just hide the vPASID capability when the user
> > > calls GET_INFO on the 2nd mdev in above scenario. In this way the
> > > user even doesn't need to know such restriction at all and both mdevs
> > > can be assigned to a single VM w/o any problem.
> > >
> >
> > The restriction only probably happens when two mdevs are assigned to one
> > VM,
> > how could the vfio device driver get to know this info to accurately hide
> > the vPASID capability for the 2nd mdev when VFIO_DEVICE_GET_INFO?
> > There is no
> > need to do this in other cases.
> >
>
> I suppose the driver can detect it via whether two mdevs are opened by a
> single process.
Just have the kernel some ID for the PASID numberspace - devices with
the same ID have to be represented as a single RID.
Jason
next prev parent reply other threads:[~2021-07-22 16:30 UTC|newest]
Thread overview: 120+ 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 7:48 ` Tian, Kevin
2021-07-09 21:50 ` Alex Williamson
2021-07-09 21:50 ` Alex Williamson
2021-07-12 1:22 ` Tian, Kevin
2021-07-12 1:22 ` Tian, Kevin
2021-07-12 18:41 ` Alex Williamson
2021-07-12 18:41 ` Alex Williamson
2021-07-12 23:41 ` Tian, Kevin
2021-07-12 23:41 ` Tian, Kevin
2021-07-12 23:56 ` Tian, Kevin
2021-07-12 23:56 ` Tian, Kevin
2021-07-13 12:55 ` Jason Gunthorpe
2021-07-13 12:55 ` Jason Gunthorpe
2021-07-13 16:26 ` Alex Williamson
2021-07-13 16:26 ` Alex Williamson
2021-07-13 16:32 ` Jason Gunthorpe
2021-07-13 16:32 ` Jason Gunthorpe
2021-07-13 22:48 ` Tian, Kevin
2021-07-13 22:48 ` Tian, Kevin
2021-07-13 23:02 ` Jason Gunthorpe
2021-07-13 23:02 ` Jason Gunthorpe
2021-07-13 23:20 ` Tian, Kevin
2021-07-13 23:20 ` Tian, Kevin
2021-07-13 23:22 ` Jason Gunthorpe
2021-07-13 23:22 ` Jason Gunthorpe
2021-07-13 23:24 ` Tian, Kevin
2021-07-13 23:24 ` Tian, Kevin
2021-07-15 3:20 ` Shenming Lu
2021-07-15 3:20 ` Shenming Lu
2021-07-15 3:55 ` Tian, Kevin
2021-07-15 3:55 ` Tian, Kevin
2021-07-15 6:29 ` Shenming Lu
2021-07-15 6:29 ` Shenming Lu
2021-07-15 6:49 ` Tian, Kevin
2021-07-15 6:49 ` Tian, Kevin
2021-07-15 8:14 ` Shenming Lu
2021-07-15 8:14 ` Shenming Lu
2021-07-15 12:48 ` Jason Gunthorpe via iommu
2021-07-15 12:48 ` Jason Gunthorpe
2021-07-15 13:57 ` Raj, Ashok
2021-07-15 13:57 ` Raj, Ashok
2021-07-15 15:23 ` Jason Gunthorpe via iommu
2021-07-15 15:23 ` Jason Gunthorpe
2021-07-15 16:21 ` Raj, Ashok
2021-07-15 16:21 ` Raj, Ashok
2021-07-15 17:18 ` Jason Gunthorpe via iommu
2021-07-15 17:18 ` Jason Gunthorpe
2021-07-15 17:48 ` Raj, Ashok
2021-07-15 17:48 ` Raj, Ashok
2021-07-15 17:53 ` Jason Gunthorpe via iommu
2021-07-15 17:53 ` Jason Gunthorpe
2021-07-15 18:05 ` Raj, Ashok
2021-07-15 18:05 ` Raj, Ashok
2021-07-15 18:13 ` Jason Gunthorpe via iommu
2021-07-15 18:13 ` Jason Gunthorpe
2021-07-16 1:20 ` Tian, Kevin
2021-07-16 1:20 ` Tian, Kevin
2021-07-16 12:20 ` Shenming Lu
2021-07-16 12:20 ` Shenming Lu
2021-07-21 2:13 ` Tian, Kevin
2021-07-21 2:13 ` Tian, Kevin
2021-07-22 16:30 ` Jason Gunthorpe via iommu [this message]
2021-07-22 16:30 ` Jason Gunthorpe
2021-07-16 18:30 ` Jason Gunthorpe via iommu
2021-07-16 18:30 ` Jason Gunthorpe
2021-07-21 2:11 ` Tian, Kevin
2021-07-21 2:11 ` Tian, Kevin
2021-07-26 4:50 ` David Gibson
2021-07-26 4:50 ` David Gibson
2021-07-28 4:04 ` Tian, Kevin
2021-07-28 4:04 ` Tian, Kevin
2021-08-03 1:50 ` David Gibson
2021-08-03 1:50 ` David Gibson
2021-08-03 3:19 ` Tian, Kevin
2021-08-03 3:19 ` Tian, Kevin
2021-08-06 4:45 ` David Gibson
2021-08-06 4:45 ` David Gibson
2021-08-06 12:32 ` Jason Gunthorpe via iommu
2021-08-06 12:32 ` Jason Gunthorpe
2021-08-10 6:10 ` David Gibson
2021-08-10 6:10 ` David Gibson
2021-08-09 8:34 ` Tian, Kevin
2021-08-09 8:34 ` Tian, Kevin
2021-08-10 4:47 ` David Gibson
2021-08-10 4:47 ` David Gibson
2021-08-10 6:04 ` Tian, Kevin
2021-08-10 6:04 ` Tian, Kevin
2021-07-30 14:51 ` Jason Gunthorpe via iommu
2021-07-30 14:51 ` Jason Gunthorpe
2021-08-02 2:49 ` Tian, Kevin
2021-08-02 2:49 ` Tian, Kevin
2021-08-04 14:04 ` Jason Gunthorpe via iommu
2021-08-04 14:04 ` Jason Gunthorpe
2021-08-04 22:59 ` Tian, Kevin
2021-08-04 22:59 ` Tian, Kevin
2021-08-05 11:27 ` Jason Gunthorpe via iommu
2021-08-05 11:27 ` Jason Gunthorpe
2021-08-05 22:44 ` Tian, Kevin
2021-08-05 22:44 ` Tian, Kevin
2021-08-06 4:47 ` David Gibson
2021-08-06 4:47 ` David Gibson
2021-08-03 1:58 ` David Gibson
2021-08-03 1:58 ` David Gibson
2021-08-04 14:07 ` Jason Gunthorpe via iommu
2021-08-04 14:07 ` Jason Gunthorpe
2021-08-06 4:24 ` David Gibson
2021-08-06 4:24 ` David Gibson
2021-07-26 8:14 ` Jean-Philippe Brucker
2021-07-26 8:14 ` Jean-Philippe Brucker
2021-07-28 4:05 ` Tian, Kevin
2021-07-28 4:05 ` Tian, Kevin
2021-08-04 15:59 ` Eric Auger
2021-08-04 15:59 ` Eric Auger
2021-08-05 0:36 ` Tian, Kevin
2021-08-05 0:36 ` Tian, Kevin
2021-08-10 7:17 ` Eric Auger
2021-08-10 7:17 ` Eric Auger
2021-08-10 9:00 ` Tian, Kevin
2021-08-10 9:00 ` Tian, Kevin
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=20210722163038.GM1117491@nvidia.com \
--to=iommu@lists.linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=corbet@lwn.net \
--cc=dave.jiang@intel.com \
--cc=david@gibson.dropbear.id.au \
--cc=dwmw2@infradead.org \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--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=wanghaibin.wang@huawei.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.