From: "Tian, Kevin" <kevin.tian@intel.com> To: 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: Eric Auger <eric.auger@redhat.com>, Jonathan Corbet <corbet@lwn.net>, "Raj, Ashok" <ashok.raj@intel.com>, "Tian, Kevin" <kevin.tian@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: Plan for /dev/ioasid RFC v2 Date: Mon, 7 Jun 2021 02:58:18 +0000 [thread overview] Message-ID: <MWHPR11MB188699D0B9C10EB51686C4138C389@MWHPR11MB1886.namprd11.prod.outlook.com> (raw) 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; - (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); - (Jason) Addition of device label allows per-device capability/format check before IOASIDs are created. This leads to another major uAPI change in v2 - specify format info when creating an IOASID (mapping protocol, nesting, coherent, etc.). User is expected to check per-device format and then set proper format for IOASID upon to-be-attached device; - (Jason/David) No restriction on map/unmap vs. bind/invalidate. They can be used in either parent or child; - (David) Change IOASID_GET_INFO to report permitted range instead of reserved IOVA ranges. This works better for PPC; - (Jason) For helper functions, expect to have explicit bus-type wrappers e.g. ioasid_pci_device_attach; (Not adopted) - (Parav) Make page pinning a syscall; - (Jason. W/Enrico) one I/O page table per fd; - (David) Replace IOASID_REGISTER_MEMORY through another ioasid nesting (sort of passthrough mode). Need more thinking. v2 will not change this part; Thanks Kevin
WARNING: multiple messages have this Message-ID (diff)
From: "Tian, Kevin" <kevin.tian@intel.com> To: 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: "Tian, Kevin" <kevin.tian@intel.com>, "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: Plan for /dev/ioasid RFC v2 Date: Mon, 7 Jun 2021 02:58:18 +0000 [thread overview] Message-ID: <MWHPR11MB188699D0B9C10EB51686C4138C389@MWHPR11MB1886.namprd11.prod.outlook.com> (raw) 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; - (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); - (Jason) Addition of device label allows per-device capability/format check before IOASIDs are created. This leads to another major uAPI change in v2 - specify format info when creating an IOASID (mapping protocol, nesting, coherent, etc.). User is expected to check per-device format and then set proper format for IOASID upon to-be-attached device; - (Jason/David) No restriction on map/unmap vs. bind/invalidate. They can be used in either parent or child; - (David) Change IOASID_GET_INFO to report permitted range instead of reserved IOVA ranges. This works better for PPC; - (Jason) For helper functions, expect to have explicit bus-type wrappers e.g. ioasid_pci_device_attach; (Not adopted) - (Parav) Make page pinning a syscall; - (Jason. W/Enrico) one I/O page table per fd; - (David) Replace IOASID_REGISTER_MEMORY through another ioasid nesting (sort of passthrough mode). Need more thinking. v2 will not change this part; Thanks Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next reply other threads:[~2021-06-07 2:58 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-07 2:58 Tian, Kevin [this message] 2021-06-07 2:58 ` Plan for /dev/ioasid RFC v2 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 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=MWHPR11MB188699D0B9C10EB51686C4138C389@MWHPR11MB1886.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: 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.