From: Jason Gunthorpe <jgg@nvidia.com> To: "Liu, Yi L" <yi.l.liu@intel.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, Jason Wang <jasowang@redhat.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "eric.auger@redhat.com" <eric.auger@redhat.com>, "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>, "joro@8bytes.org" <joro@8bytes.org>, "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, "Tian, Jun J" <jun.j.tian@intel.com>, "Sun, Yi Y" <yi.y.sun@intel.com>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "peterx@redhat.com" <peterx@redhat.com>, "Wu, Hao" <hao.wu@intel.com>, "stefanha@gmail.com" <stefanha@gmail.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Zhu, Lingshan" <lingshan.zhu@intel.com> Subject: Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs Date: Tue, 20 Oct 2020 11:02:17 -0300 [thread overview] Message-ID: <20201020140217.GI6219@nvidia.com> (raw) In-Reply-To: <DM5PR11MB14354A8A126E686A5F20FEC2C31F0@DM5PR11MB1435.namprd11.prod.outlook.com> On Tue, Oct 20, 2020 at 10:21:41AM +0000, Liu, Yi L wrote: > > I'm sure there will be some > > weird overlaps because we can't delete any of the existing VFIO APIs, but > > that > > should not be a blocker. > > but the weird thing is what we should consider. And it perhaps not just > overlap, it may be a re-definition of VFIO container. As I mentioned, VFIO > container is IOMMU context from the day it was defined. It could be the > blocker. :-( So maybe you have to broaden the VFIO container to be usable by other subsystems. The discussion here is about what the uAPI should look like in a fairly abstract way. When we say 'dev/sva' it just some placeholder for a shared cdev that provides the necessary dis-aggregated functionality It could be an existing cdev with broader functionaltiy, it could really be /dev/iommu, etc. This is up to the folks building it to decide. > I'm not expert on vDPA for now, but I saw you three open source > veterans have a similar idea for a place to cover IOMMU handling, > I think it may be a valuable thing to do. I said "may be" as I'm not > sure about Alex's opinion on such idea. But the sure thing is this > idea may introduce weird overlap even re-definition of existing > thing as I replied above. We need to evaluate the impact and mature > the idea step by step. This has happened before, uAPIs do get obsoleted and replaced with more general/better versions. It is often too hard to create a uAPI that lasts for decades when the HW landscape is constantly changing and sometime a reset is needed. The jump to shared PASID based IOMMU feels like one of those moments here. > > Whoever provides the vIOMMU emulation and relays the page fault to the guest > > has to translate the RID - > > that's the point. But the device info (especially the sub-device info) is > within the passthru framework (e.g. VFIO). So page fault reporting needs > to go through passthru framework. > > > what does that have to do with VFIO? > > > > How will VPDA provide the vIOMMU emulation? > > a pardon here. I believe vIOMMU emulation should be based on IOMMU vendor > specification, right? you may correct me if I'm missing anything. I'm asking how will VDPA translate the RID when VDPA triggers a page fault that has to be relayed to the guest. VDPA also has virtual PCI devices it creates. We can't rely on VFIO to be the place that the vIOMMU lives because it excludes/complicates everything that is not VFIO from using that stuff. Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com> To: "Liu, Yi L" <yi.l.liu@intel.com> Cc: "Tian, Jun J" <jun.j.tian@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "stefanha@gmail.com" <stefanha@gmail.com>, Jason Wang <jasowang@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "Sun, Yi Y" <yi.y.sun@intel.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "Zhu, Lingshan" <lingshan.zhu@intel.com>, "Wu, Hao" <hao.wu@intel.com> Subject: Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs Date: Tue, 20 Oct 2020 11:02:17 -0300 [thread overview] Message-ID: <20201020140217.GI6219@nvidia.com> (raw) In-Reply-To: <DM5PR11MB14354A8A126E686A5F20FEC2C31F0@DM5PR11MB1435.namprd11.prod.outlook.com> On Tue, Oct 20, 2020 at 10:21:41AM +0000, Liu, Yi L wrote: > > I'm sure there will be some > > weird overlaps because we can't delete any of the existing VFIO APIs, but > > that > > should not be a blocker. > > but the weird thing is what we should consider. And it perhaps not just > overlap, it may be a re-definition of VFIO container. As I mentioned, VFIO > container is IOMMU context from the day it was defined. It could be the > blocker. :-( So maybe you have to broaden the VFIO container to be usable by other subsystems. The discussion here is about what the uAPI should look like in a fairly abstract way. When we say 'dev/sva' it just some placeholder for a shared cdev that provides the necessary dis-aggregated functionality It could be an existing cdev with broader functionaltiy, it could really be /dev/iommu, etc. This is up to the folks building it to decide. > I'm not expert on vDPA for now, but I saw you three open source > veterans have a similar idea for a place to cover IOMMU handling, > I think it may be a valuable thing to do. I said "may be" as I'm not > sure about Alex's opinion on such idea. But the sure thing is this > idea may introduce weird overlap even re-definition of existing > thing as I replied above. We need to evaluate the impact and mature > the idea step by step. This has happened before, uAPIs do get obsoleted and replaced with more general/better versions. It is often too hard to create a uAPI that lasts for decades when the HW landscape is constantly changing and sometime a reset is needed. The jump to shared PASID based IOMMU feels like one of those moments here. > > Whoever provides the vIOMMU emulation and relays the page fault to the guest > > has to translate the RID - > > that's the point. But the device info (especially the sub-device info) is > within the passthru framework (e.g. VFIO). So page fault reporting needs > to go through passthru framework. > > > what does that have to do with VFIO? > > > > How will VPDA provide the vIOMMU emulation? > > a pardon here. I believe vIOMMU emulation should be based on IOMMU vendor > specification, right? you may correct me if I'm missing anything. I'm asking how will VDPA translate the RID when VDPA triggers a page fault that has to be relayed to the guest. VDPA also has virtual PCI devices it creates. We can't rely on VFIO to be the place that the vIOMMU lives because it excludes/complicates everything that is not VFIO from using that stuff. Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-10-20 14:02 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-12 8:38 (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs Tian, Kevin 2020-10-12 8:38 ` Tian, Kevin 2020-10-13 6:22 ` Jason Wang 2020-10-13 6:22 ` Jason Wang 2020-10-14 3:08 ` Tian, Kevin 2020-10-14 3:08 ` Tian, Kevin 2020-10-14 23:10 ` Alex Williamson 2020-10-14 23:10 ` Alex Williamson 2020-10-15 7:02 ` Jason Wang 2020-10-15 7:02 ` Jason Wang 2020-10-15 6:52 ` Jason Wang 2020-10-15 6:52 ` Jason Wang 2020-10-15 7:58 ` Tian, Kevin 2020-10-15 7:58 ` Tian, Kevin 2020-10-15 8:40 ` Jason Wang 2020-10-15 8:40 ` Jason Wang 2020-10-15 10:14 ` Liu, Yi L 2020-10-15 10:14 ` Liu, Yi L 2020-10-20 6:18 ` Jason Wang 2020-10-20 6:18 ` Jason Wang 2020-10-20 8:19 ` Liu, Yi L 2020-10-20 8:19 ` Liu, Yi L 2020-10-20 9:19 ` Jason Wang 2020-10-20 9:19 ` Jason Wang 2020-10-20 9:40 ` Liu, Yi L 2020-10-20 9:40 ` Liu, Yi L 2020-10-20 13:54 ` Jason Gunthorpe 2020-10-20 13:54 ` Jason Gunthorpe 2020-10-20 14:00 ` Liu, Yi L 2020-10-20 14:00 ` Liu, Yi L 2020-10-20 14:05 ` Jason Gunthorpe 2020-10-20 14:05 ` Jason Gunthorpe 2020-10-20 14:09 ` Liu, Yi L 2020-10-20 14:09 ` Liu, Yi L 2020-10-13 10:27 ` Jean-Philippe Brucker 2020-10-13 10:27 ` Jean-Philippe Brucker 2020-10-14 2:11 ` Tian, Kevin 2020-10-14 2:11 ` Tian, Kevin 2020-10-14 3:16 ` Tian, Kevin 2020-10-14 3:16 ` Tian, Kevin 2020-10-16 15:36 ` Jason Gunthorpe 2020-10-16 15:36 ` Jason Gunthorpe 2020-10-19 8:39 ` Liu, Yi L 2020-10-19 8:39 ` Liu, Yi L 2020-10-19 14:25 ` Jason Gunthorpe 2020-10-19 14:25 ` Jason Gunthorpe 2020-10-20 10:21 ` Liu, Yi L 2020-10-20 10:21 ` Liu, Yi L 2020-10-20 14:02 ` Jason Gunthorpe [this message] 2020-10-20 14:02 ` Jason Gunthorpe 2020-10-20 14:19 ` Liu, Yi L 2020-10-20 14:19 ` Liu, Yi L 2020-10-21 2:21 ` Jason Wang 2020-10-21 2:21 ` Jason Wang 2020-10-20 16:24 ` Raj, Ashok 2020-10-20 16:24 ` Raj, Ashok 2020-10-20 17:03 ` Jason Gunthorpe 2020-10-20 17:03 ` Jason Gunthorpe 2020-10-20 19:51 ` Raj, Ashok 2020-10-20 19:51 ` Raj, Ashok 2020-10-20 19:55 ` Jason Gunthorpe 2020-10-20 19:55 ` Jason Gunthorpe 2020-10-20 20:08 ` Raj, Ashok 2020-10-20 20:08 ` Raj, Ashok 2020-10-20 20:14 ` Jason Gunthorpe 2020-10-20 20:14 ` Jason Gunthorpe 2020-10-20 20:27 ` Raj, Ashok 2020-10-20 20:27 ` Raj, Ashok 2020-10-21 11:48 ` Jason Gunthorpe 2020-10-21 11:48 ` Jason Gunthorpe 2020-10-21 17:51 ` Raj, Ashok 2020-10-21 17:51 ` Raj, Ashok 2020-10-21 18:24 ` Jason Gunthorpe 2020-10-21 18:24 ` Jason Gunthorpe 2020-10-21 20:03 ` Raj, Ashok 2020-10-21 20:03 ` Raj, Ashok 2020-10-21 23:32 ` Jason Gunthorpe 2020-10-21 23:32 ` Jason Gunthorpe 2020-10-21 23:53 ` Raj, Ashok 2020-10-21 23:53 ` Raj, Ashok 2020-10-22 2:55 ` Jason Wang 2020-10-22 2:55 ` Jason Wang 2020-10-22 3:54 ` Liu, Yi L 2020-10-22 3:54 ` Liu, Yi L 2020-10-22 4:38 ` Jason Wang 2020-10-22 4:38 ` Jason Wang 2020-11-03 9:52 ` joro 2020-11-03 9:52 ` joro 2020-11-03 12:56 ` Jason Gunthorpe 2020-11-03 12:56 ` Jason Gunthorpe 2020-11-03 13:18 ` joro 2020-11-03 13:18 ` joro 2020-11-03 13:23 ` Jason Gunthorpe 2020-11-03 13:23 ` Jason Gunthorpe 2020-11-03 14:03 ` joro 2020-11-03 14:03 ` joro 2020-11-03 14:06 ` Jason Gunthorpe 2020-11-03 14:06 ` Jason Gunthorpe 2020-11-03 14:35 ` joro 2020-11-03 14:35 ` joro 2020-11-03 15:22 ` Jason Gunthorpe 2020-11-03 15:22 ` Jason Gunthorpe 2020-11-03 16:55 ` joro 2020-11-03 16:55 ` joro 2020-11-03 17:48 ` Jason Gunthorpe 2020-11-03 17:48 ` Jason Gunthorpe 2020-11-03 19:14 ` joro 2020-11-03 19:14 ` joro 2020-11-04 19:29 ` Jason Gunthorpe 2020-11-04 19:29 ` Jason Gunthorpe
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=20201020140217.GI6219@nvidia.com \ --to=jgg@nvidia.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --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=joro@8bytes.org \ --cc=jun.j.tian@intel.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=lingshan.zhu@intel.com \ --cc=mst@redhat.com \ --cc=peterx@redhat.com \ --cc=stefanha@gmail.com \ --cc=yi.l.liu@intel.com \ --cc=yi.y.sun@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.