From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "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>,
"parav@mellanox.com" <parav@mellanox.com>,
Alex Williamson <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>,
Shenming Lu <lushenming@huawei.com>,
"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: Tue, 13 Jul 2021 09:55:03 -0300 [thread overview]
Message-ID: <20210713125503.GC136586@nvidia.com> (raw)
In-Reply-To: <BL1PR11MB54299D9554D71F53D74E1E378C159@BL1PR11MB5429.namprd11.prod.outlook.com>
On Mon, Jul 12, 2021 at 11:56:24PM +0000, Tian, Kevin wrote:
> Maybe I misunderstood your question. Are you specifically worried
> about establishing the security context for a mdev vs. for its
> parent?
The way to think about the cookie, and the device bind/attach in
general, is as taking control of a portion of the IOMMU routing:
- RID
- RID + PASID
- "software"
For the first two there can be only one device attachment per value so
the cookie is unambiguous.
For "software" the iommu layer has little to do with this - everything
is constructed outside by the mdev. If the mdev wishes to communicate
on /dev/iommu using the cookie then it has to do so using some iommufd
api and we can convay the proper device at that point.
Kevin didn't show it, but along side the PCI attaches:
struct iommu_attach_data * iommu_pci_device_attach(
struct iommu_dev *dev, struct pci_device *pdev,
u32 ioasid);
There would also be a software attach for mdev:
struct iommu_attach_data * iommu_sw_device_attach(
struct iommu_dev *dev, struct device *pdev, u32 ioasid);
Which does not connect anything to the iommu layer.
It would have to return something that allows querying the IO page
table, and the mdev would use that API instead of vfio_pin_pages().
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-07-13 12:55 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 [this message]
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 via iommu
2021-07-15 13:57 ` Raj, Ashok
2021-07-15 15:23 ` Jason Gunthorpe via iommu
2021-07-15 16:21 ` Raj, Ashok
2021-07-15 17:18 ` Jason Gunthorpe via iommu
2021-07-15 17:48 ` Raj, Ashok
2021-07-15 17:53 ` Jason Gunthorpe via iommu
2021-07-15 18:05 ` Raj, Ashok
2021-07-15 18:13 ` Jason Gunthorpe via iommu
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 via iommu
2021-07-16 18:30 ` Jason Gunthorpe via iommu
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 via iommu
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 via iommu
2021-08-02 2:49 ` Tian, Kevin
2021-08-04 14:04 ` Jason Gunthorpe via iommu
2021-08-04 22:59 ` Tian, Kevin
2021-08-05 11:27 ` Jason Gunthorpe via iommu
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 via iommu
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
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=20210713125503.GC136586@nvidia.com \
--to=jgg@nvidia.com \
--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=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--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 \
/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).