From: Eric Auger <eric.auger@redhat.com> To: "Tian, Kevin" <kevin.tian@intel.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> 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>, Joerg Roedel <joro@8bytes.org>, LKML <linux-kernel@vger.kernel.org>, Lu Baolu <baolu.lu@linux.intel.com> Subject: Re: Plan for /dev/ioasid RFC v2 Date: Wed, 9 Jun 2021 12:14:48 +0200 [thread overview] Message-ID: <8a3f2bc6-79b7-5dfb-492a-21c0af7b9c2c@redhat.com> (raw) In-Reply-To: <MWHPR11MB1886FEFB5C8358EB65DBEA1A8C369@MWHPR11MB1886.namprd11.prod.outlook.com> Hi Kevin, On 6/9/21 11:37 AM, Tian, Kevin wrote: >> From: Eric Auger <eric.auger@redhat.com> >> Sent: Wednesday, June 9, 2021 4:15 PM >> >> Hi Kevin, >> >> On 6/7/21 4:58 AM, Tian, Kevin wrote: >>> Hi, all, >>> >>> We plan to work on v2 now, given many good comments already received >>> and substantial changes envisioned. This is a very complex topic with >>> many sub-threads being discussed. To ensure that I didn't miss valuable >>> suggestions (and also keep everyone on the same page), here I'd like to >>> provide a list of planned changes in my mind. Please let me know if >>> anything important is lost. :) >>> >>> -- >>> >>> (Remaining opens in v1) >>> >>> - Protocol between kvm/vfio/ioasid for wbinvd/no-snoop. I'll see how >>> much can be refined based on discussion progress when v2 is out; >>> >>> - Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully >>> convinced yet. Based on discussion v2 will continue to have ioasid uAPI >>> being device-centric (but it's fine for vfio to be group-centric). A new >>> section will be added to elaborate this part; >>> >>> - PASID virtualization (section 4) has not been thoroughly discussed yet. >>> Jason gave some suggestion on how to categorize intended usages. >>> I will rephrase this section and hope more discussions can be held for >>> it in v2; >>> >>> (Adopted suggestions) >>> >>> - (Jason) Rename /dev/ioasid to /dev/iommu (so does uAPI e.g. IOASID >>> _XXX to IOMMU_XXX). One suggestion (Jason) was to also rename >>> RID+PASID to SID+SSID. But given the familiarity of the former, I will >>> still use RID+PASID in v2 to ease the discussoin; >>> >>> - (Jason) v1 prevents one device from binding to multiple ioasid_fd's. This >>> will be fixed in v2; >>> >>> - (Jean/Jason) No need to track guest I/O page tables on ARM/AMD. >> When >>> a pasid table is bound, it becomes a container for all guest I/O page >> tables; >> while I am totally in line with that change, I guess we need to revisit >> the invalidate ioctl >> to support PASID table invalidation. > Yes, this is planned when doing this change. OK > >>> - (Jean/Jason) Accordingly a device label is required so iotlb invalidation >>> and fault handling can both support per-device operation. Per Jean's >>> suggestion, this label will come from userspace (when VFIO_BIND_ >>> IOASID_FD); >> what is not totally clear to me is the correspondance between this label >> and the SID/SSID tuple. >> My understanding is it rather maps to the SID because you can attach >> several ioasids to the device. >> So it is not clear to me how you reconstruct the SSID info >> > Yes, device handle maps to SID. The fault data reported to userspace > will include {device_label, ioasid, vendor_fault_data}. In your case > I believe SSID will be included in vendor_fault_data thus no reconstruct > required. For Intel the user could figure out vPASID according to device_ > label and ioasid, i.e. no need to include PASID info in vendor_fault_data. OK that works. Thanks Eric > > Thanks > Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@redhat.com> To: "Tian, Kevin" <kevin.tian@intel.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> Cc: "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>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Kirti Wankhede <kwankhede@nvidia.com>, Robin Murphy <robin.murphy@arm.com> Subject: Re: Plan for /dev/ioasid RFC v2 Date: Wed, 9 Jun 2021 12:14:48 +0200 [thread overview] Message-ID: <8a3f2bc6-79b7-5dfb-492a-21c0af7b9c2c@redhat.com> (raw) In-Reply-To: <MWHPR11MB1886FEFB5C8358EB65DBEA1A8C369@MWHPR11MB1886.namprd11.prod.outlook.com> Hi Kevin, On 6/9/21 11:37 AM, Tian, Kevin wrote: >> From: Eric Auger <eric.auger@redhat.com> >> Sent: Wednesday, June 9, 2021 4:15 PM >> >> Hi Kevin, >> >> On 6/7/21 4:58 AM, Tian, Kevin wrote: >>> Hi, all, >>> >>> We plan to work on v2 now, given many good comments already received >>> and substantial changes envisioned. This is a very complex topic with >>> many sub-threads being discussed. To ensure that I didn't miss valuable >>> suggestions (and also keep everyone on the same page), here I'd like to >>> provide a list of planned changes in my mind. Please let me know if >>> anything important is lost. :) >>> >>> -- >>> >>> (Remaining opens in v1) >>> >>> - Protocol between kvm/vfio/ioasid for wbinvd/no-snoop. I'll see how >>> much can be refined based on discussion progress when v2 is out; >>> >>> - Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully >>> convinced yet. Based on discussion v2 will continue to have ioasid uAPI >>> being device-centric (but it's fine for vfio to be group-centric). A new >>> section will be added to elaborate this part; >>> >>> - PASID virtualization (section 4) has not been thoroughly discussed yet. >>> Jason gave some suggestion on how to categorize intended usages. >>> I will rephrase this section and hope more discussions can be held for >>> it in v2; >>> >>> (Adopted suggestions) >>> >>> - (Jason) Rename /dev/ioasid to /dev/iommu (so does uAPI e.g. IOASID >>> _XXX to IOMMU_XXX). One suggestion (Jason) was to also rename >>> RID+PASID to SID+SSID. But given the familiarity of the former, I will >>> still use RID+PASID in v2 to ease the discussoin; >>> >>> - (Jason) v1 prevents one device from binding to multiple ioasid_fd's. This >>> will be fixed in v2; >>> >>> - (Jean/Jason) No need to track guest I/O page tables on ARM/AMD. >> When >>> a pasid table is bound, it becomes a container for all guest I/O page >> tables; >> while I am totally in line with that change, I guess we need to revisit >> the invalidate ioctl >> to support PASID table invalidation. > Yes, this is planned when doing this change. OK > >>> - (Jean/Jason) Accordingly a device label is required so iotlb invalidation >>> and fault handling can both support per-device operation. Per Jean's >>> suggestion, this label will come from userspace (when VFIO_BIND_ >>> IOASID_FD); >> what is not totally clear to me is the correspondance between this label >> and the SID/SSID tuple. >> My understanding is it rather maps to the SID because you can attach >> several ioasids to the device. >> So it is not clear to me how you reconstruct the SSID info >> > Yes, device handle maps to SID. The fault data reported to userspace > will include {device_label, ioasid, vendor_fault_data}. In your case > I believe SSID will be included in vendor_fault_data thus no reconstruct > required. For Intel the user could figure out vPASID according to device_ > label and ioasid, i.e. no need to include PASID info in vendor_fault_data. OK that works. Thanks Eric > > Thanks > Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-09 10:14 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-07 2:58 Plan for /dev/ioasid RFC v2 Tian, Kevin 2021-06-07 2:58 ` Tian, Kevin 2021-06-09 8:14 ` Eric Auger 2021-06-09 8:14 ` Eric Auger 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 10:14 ` Eric Auger [this message] 2021-06-09 10:14 ` Eric Auger 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 18:49 ` Jason Gunthorpe 2021-06-09 18:49 ` Jason Gunthorpe 2021-06-10 15:38 ` Alex Williamson 2021-06-10 15:38 ` Alex Williamson 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 21:38 ` Alex Williamson 2021-06-11 21:38 ` Alex Williamson 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:22 ` Alex Williamson 2021-06-14 3:22 ` Alex Williamson 2021-06-15 1:05 ` Tian, Kevin 2021-06-15 1:05 ` Tian, Kevin 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 16:56 ` Alex Williamson 2021-06-15 16:56 ` Alex Williamson 2021-06-16 6:53 ` Tian, Kevin 2021-06-16 6:53 ` Tian, Kevin 2021-06-24 4:50 ` David Gibson 2021-06-24 4:50 ` David Gibson 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 19:38 ` Alex Williamson 2021-06-11 19:38 ` Alex Williamson 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 16:57 ` Alex Williamson 2021-06-12 16:57 ` Alex Williamson 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 16:28 ` Alex Williamson 2021-06-14 16:28 ` Alex Williamson 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-15 2:31 ` Tian, Kevin 2021-06-15 2:31 ` Tian, Kevin 2021-06-15 16:12 ` Alex Williamson 2021-06-15 16:12 ` Alex Williamson 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 19:39 ` Alex Williamson 2021-06-16 19:39 ` Alex Williamson 2021-06-17 3:39 ` Liu Yi L 2021-06-17 3:39 ` Liu Yi L 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 21:14 ` Alex Williamson 2021-06-17 21:14 ` Alex Williamson 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-24 4:26 ` David Gibson 2021-06-24 4:26 ` David Gibson 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 12:22 ` Lu Baolu 2021-06-24 12:22 ` Lu Baolu 2021-06-24 4:23 ` David Gibson 2021-06-24 4:23 ` David Gibson 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:51 ` Alex Williamson 2021-06-18 15:51 ` Alex Williamson 2021-06-24 4:29 ` David Gibson 2021-06-24 4:29 ` David Gibson 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-17 5:29 ` David Gibson 2021-06-17 5:29 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-24 4:37 ` David Gibson 2021-06-24 4:37 ` David Gibson 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-10 5:50 ` Lu Baolu 2021-06-10 5:50 ` Lu Baolu 2021-06-17 5:22 ` David Gibson 2021-06-17 5:22 ` David Gibson 2021-06-18 5:21 ` Lu Baolu 2021-06-18 5:21 ` Lu Baolu 2021-06-24 4:03 ` David Gibson 2021-06-24 4:03 ` David Gibson 2021-06-24 13:42 ` Lu Baolu 2021-06-24 13:42 ` Lu Baolu 2021-06-17 4:45 ` David Gibson 2021-06-17 4:45 ` David Gibson 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-24 4:07 ` David Gibson 2021-06-24 4:07 ` David Gibson
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=8a3f2bc6-79b7-5dfb-492a-21c0af7b9c2c@redhat.com \ --to=eric.auger@redhat.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=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=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=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: linkBe 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.