From: Alex Williamson <alex.williamson@redhat.com> To: "Raj, Ashok" <ashok.raj@intel.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "eric.auger@redhat.com" <eric.auger@redhat.com>, "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>, "joro@8bytes.org" <joro@8bytes.org>, "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>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Wu, Hao" <hao.wu@intel.com>, Bjorn Helgaas <bhelgaas@google.com>, Don Dutile <ddutile@redhat.com> Subject: Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs Date: Wed, 8 Apr 2020 10:19:40 -0600 [thread overview] Message-ID: <20200408101940.3459943d@w520.home> (raw) In-Reply-To: <20200408040021.GS67127@otc-nc-03> On Tue, 7 Apr 2020 21:00:21 -0700 "Raj, Ashok" <ashok.raj@intel.com> wrote: > Hi Alex > > + Bjorn + Don > FWIW I can't understand why PCI SIG went different ways with ATS, > where its enumerated on PF and VF. But for PASID and PRI its only > in PF. > > I'm checking with our internal SIG reps to followup on that. > > On Tue, Apr 07, 2020 at 09:58:01AM -0600, Alex Williamson wrote: > > > Is there vendor guarantee that hidden registers will locate at the > > > same offset between PF and VF config space? > > > > I'm not sure if the spec really precludes hidden registers, but the > > fact that these registers are explicitly outside of the capability > > chain implies they're only intended for device specific use, so I'd say > > there are no guarantees about anything related to these registers. > > As you had suggested in the other thread, we could consider > using the same offset as in PF, but even that's a better guess > still not reliable. > > The other option is to maybe extend driver ops in the PF to expose > where the offsets should be. Sort of adding the quirk in the > implementation. > > I'm not sure how prevalent are PASID and PRI in VF devices. If SIG is resisting > making VF's first class citizen, we might ask them to add some verbiage > to suggest leave the same offsets as PF open to help emulation software. Even if we know where to expose these capabilities on the VF, it's not clear to me how we can actually virtualize the capability itself. If the spec defines, for example, an enable bit as r/w then software that interacts with that register expects the bit is settable. There's no protocol for "try to set the bit and re-read it to see if the hardware accepted it". Therefore a capability with a fixed enable bit representing the state of the PF, not settable by the VF, is disingenuous to the spec. If what we're trying to do is expose that PASID and PRI are enabled on the PF to a VF driver, maybe duplicating the PF capabilities on the VF without the ability to control it is not the right approach. Maybe we need new capabilities exposing these as slave features that cannot be controlled? We could define our own vendor capability for this, but of course we have both the where to put it in config space issue, as well as the issue of trying to push an ad-hoc standard. vfio could expose these as device features rather than emulating capabilities, but that still leaves a big gap between vfio in the hypervisor and the driver in the guest VM. That might still help push the responsibility and policy for how to expose it to the VM as a userspace problem though. I agree though, I don't know why the SIG would preclude implementing per VF control of these features. Thanks, Alex > > FWIW, vfio started out being more strict about restricting config space > > access to defined capabilities, until... > > > > commit a7d1ea1c11b33bda2691f3294b4d735ed635535a > > Author: Alex Williamson <alex.williamson@redhat.com> > > Date: Mon Apr 1 09:04:12 2013 -0600 > > > > Cheers, > Ashok >
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com> To: "Raj, Ashok" <ashok.raj@intel.com> Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "Tian, Kevin" <kevin.tian@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Tian, Jun J" <jun.j.tian@intel.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Sun, Yi Y" <yi.y.sun@intel.com>, Bjorn Helgaas <bhelgaas@google.com>, "Wu, Hao" <hao.wu@intel.com> Subject: Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs Date: Wed, 8 Apr 2020 10:19:40 -0600 [thread overview] Message-ID: <20200408101940.3459943d@w520.home> (raw) In-Reply-To: <20200408040021.GS67127@otc-nc-03> On Tue, 7 Apr 2020 21:00:21 -0700 "Raj, Ashok" <ashok.raj@intel.com> wrote: > Hi Alex > > + Bjorn + Don > FWIW I can't understand why PCI SIG went different ways with ATS, > where its enumerated on PF and VF. But for PASID and PRI its only > in PF. > > I'm checking with our internal SIG reps to followup on that. > > On Tue, Apr 07, 2020 at 09:58:01AM -0600, Alex Williamson wrote: > > > Is there vendor guarantee that hidden registers will locate at the > > > same offset between PF and VF config space? > > > > I'm not sure if the spec really precludes hidden registers, but the > > fact that these registers are explicitly outside of the capability > > chain implies they're only intended for device specific use, so I'd say > > there are no guarantees about anything related to these registers. > > As you had suggested in the other thread, we could consider > using the same offset as in PF, but even that's a better guess > still not reliable. > > The other option is to maybe extend driver ops in the PF to expose > where the offsets should be. Sort of adding the quirk in the > implementation. > > I'm not sure how prevalent are PASID and PRI in VF devices. If SIG is resisting > making VF's first class citizen, we might ask them to add some verbiage > to suggest leave the same offsets as PF open to help emulation software. Even if we know where to expose these capabilities on the VF, it's not clear to me how we can actually virtualize the capability itself. If the spec defines, for example, an enable bit as r/w then software that interacts with that register expects the bit is settable. There's no protocol for "try to set the bit and re-read it to see if the hardware accepted it". Therefore a capability with a fixed enable bit representing the state of the PF, not settable by the VF, is disingenuous to the spec. If what we're trying to do is expose that PASID and PRI are enabled on the PF to a VF driver, maybe duplicating the PF capabilities on the VF without the ability to control it is not the right approach. Maybe we need new capabilities exposing these as slave features that cannot be controlled? We could define our own vendor capability for this, but of course we have both the where to put it in config space issue, as well as the issue of trying to push an ad-hoc standard. vfio could expose these as device features rather than emulating capabilities, but that still leaves a big gap between vfio in the hypervisor and the driver in the guest VM. That might still help push the responsibility and policy for how to expose it to the VM as a userspace problem though. I agree though, I don't know why the SIG would preclude implementing per VF control of these features. Thanks, Alex > > FWIW, vfio started out being more strict about restricting config space > > access to defined capabilities, until... > > > > commit a7d1ea1c11b33bda2691f3294b4d735ed635535a > > Author: Alex Williamson <alex.williamson@redhat.com> > > Date: Mon Apr 1 09:04:12 2013 -0600 > > > > Cheers, > Ashok > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-04-08 16:19 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-22 12:33 [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs Liu, Yi L 2020-03-22 12:33 ` Liu, Yi L 2020-03-22 12:33 ` [PATCH v1 1/2] vfio/pci: Expose PCIe PASID capability to guest Liu, Yi L 2020-03-22 12:33 ` Liu, Yi L 2020-03-31 6:39 ` Tian, Kevin 2020-03-31 6:39 ` Tian, Kevin 2020-03-31 6:42 ` Liu, Yi L 2020-03-31 6:42 ` Liu, Yi L 2020-03-22 12:33 ` [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs Liu, Yi L 2020-03-22 12:33 ` Liu, Yi L 2020-04-02 22:59 ` Alex Williamson 2020-04-02 22:59 ` Alex Williamson 2020-04-03 7:53 ` Liu, Yi L 2020-04-03 7:53 ` Liu, Yi L 2020-04-03 17:25 ` Alex Williamson 2020-04-03 17:25 ` Alex Williamson 2020-04-07 4:26 ` Tian, Kevin 2020-04-07 4:26 ` Tian, Kevin 2020-04-07 15:58 ` Alex Williamson 2020-04-07 15:58 ` Alex Williamson 2020-04-08 0:27 ` Tian, Kevin 2020-04-08 0:27 ` Tian, Kevin 2020-04-08 4:00 ` Raj, Ashok 2020-04-08 4:00 ` Raj, Ashok 2020-04-08 16:19 ` Alex Williamson [this message] 2020-04-08 16:19 ` Alex Williamson 2020-04-08 16:33 ` Raj, Ashok 2020-04-08 16:33 ` Raj, Ashok 2020-04-09 7:35 ` Jean-Philippe Brucker 2020-04-09 7:35 ` Jean-Philippe Brucker 2020-04-13 19:44 ` Alex Williamson 2020-04-13 19:44 ` Alex Williamson 2020-04-13 3:10 ` Raj, Ashok 2020-04-13 3:10 ` Raj, Ashok 2020-04-13 3:29 ` Raj, Ashok 2020-04-13 3:29 ` Raj, Ashok 2020-04-13 19:10 ` Alex Williamson 2020-04-13 19:10 ` Alex Williamson 2020-04-13 7:54 ` Tian, Kevin 2020-04-13 7:54 ` Tian, Kevin 2020-04-13 8:05 ` Tian, Kevin 2020-04-13 8:05 ` Tian, Kevin 2020-04-13 19:21 ` Alex Williamson 2020-04-13 19:21 ` Alex Williamson 2020-04-14 2:40 ` Tian, Kevin 2020-04-14 2:40 ` Tian, Kevin 2020-04-14 3:28 ` Alex Williamson 2020-04-14 3:28 ` Alex Williamson 2020-04-14 3:42 ` Tian, Kevin 2020-04-14 3:42 ` Tian, Kevin 2020-04-14 15:24 ` Alex Williamson 2020-04-14 15:24 ` Alex Williamson 2020-04-14 23:57 ` Tian, Kevin 2020-04-14 23:57 ` Tian, Kevin 2020-04-15 0:36 ` Alex Williamson 2020-04-15 0:36 ` Alex Williamson 2020-04-15 1:01 ` Tian, Kevin 2020-04-15 1:01 ` Tian, Kevin 2020-04-03 11:42 ` Liu, Yi L 2020-04-03 11:42 ` Liu, Yi L 2020-03-31 6:35 ` [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs Tian, Kevin 2020-03-31 6:35 ` Tian, Kevin 2020-03-31 7:08 ` Lu, Baolu 2020-03-31 7:08 ` Lu, Baolu 2020-04-16 22:12 ` Yan Zhao 2020-04-16 22:12 ` Yan Zhao 2020-04-16 22:33 ` Raj, Ashok 2020-04-16 22:33 ` Raj, Ashok 2020-04-17 1:13 ` Yan Zhao 2020-04-17 1:13 ` Yan Zhao
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=20200408101940.3459943d@w520.home \ --to=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=bhelgaas@google.com \ --cc=ddutile@redhat.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=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=linux-kernel@vger.kernel.org \ --cc=peterx@redhat.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.