All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>
Cc: "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"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>,
	"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>, "Lu, Baolu" <baolu.lu@intel.com>
Subject: RE: [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs
Date: Tue, 31 Mar 2020 06:35:08 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D801252@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <1584880394-11184-1-git-send-email-yi.l.liu@intel.com>

> From: Liu, Yi L <yi.l.liu@intel.com>
> Sent: Sunday, March 22, 2020 8:33 PM
> 
> From: Liu Yi L <yi.l.liu@intel.com>
> 
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> Intel platforms allows address space sharing between device DMA and
> applications. SVA can reduce programming complexity and enhance security.
> 
> To enable SVA, device needs to have PASID capability, which is a key
> capability for SVA. This patchset exposes the device's PASID capability
> to guest instead of hiding it from guest.
> 
> The second patch emulates PASID capability for VFs (Virtual Function) since
> VFs don't implement such capability per PCIe spec. This patch emulates such
> capability and expose to VM if the capability is enabled in PF (Physical
> Function).
> 
> However, there is an open for PASID emulation. If PF driver disables PASID
> capability at runtime, then it may be an issue. e.g. PF should not disable
> PASID capability if there is guest using this capability on any VF related
> to this PF. To solve it, may need to introduce a generic communication
> framework between vfio-pci driver and PF drivers. Please feel free to give
> your suggestions on it.

I'm not sure how this is addressed on bate metal today, i.e. between normal 
kernel PF and VF drivers. I look at pasid enable/disable code in intel-iommu.c.
There is no check on PF/VF dependency so far. The cap is toggled when 
attaching/detaching the PF to its domain. Let's see how IOMMU guys 
respond, and if there is a way for VF driver to block PF driver from disabling
the pasid cap when it's being actively used by VF driver, then we may
leverage the same trick in VFIO when emulation is provided to guest.

Thanks
Kevin

> 
> Regards,
> Yi Liu
> 
> Changelog:
> 	- RFC v1 -> Patch v1:
> 	  Add CONFIG_PCI_ATS #ifdef control to avoid compiling error.
> 
> Liu Yi L (2):
>   vfio/pci: Expose PCIe PASID capability to guest
>   vfio/pci: Emulate PASID/PRI capability for VFs
> 
>  drivers/vfio/pci/vfio_pci_config.c | 327
> ++++++++++++++++++++++++++++++++++++-
>  1 file changed, 324 insertions(+), 3 deletions(-)
> 
> --
> 2.7.4


WARNING: multiple messages have this Message-ID (diff)
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	"Raj, Ashok" <ashok.raj@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>,
	"Lu, Baolu" <baolu.lu@intel.com>,
	"Sun, Yi Y" <yi.y.sun@intel.com>, "Wu, Hao" <hao.wu@intel.com>
Subject: RE: [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs
Date: Tue, 31 Mar 2020 06:35:08 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D801252@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <1584880394-11184-1-git-send-email-yi.l.liu@intel.com>

> From: Liu, Yi L <yi.l.liu@intel.com>
> Sent: Sunday, March 22, 2020 8:33 PM
> 
> From: Liu Yi L <yi.l.liu@intel.com>
> 
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> Intel platforms allows address space sharing between device DMA and
> applications. SVA can reduce programming complexity and enhance security.
> 
> To enable SVA, device needs to have PASID capability, which is a key
> capability for SVA. This patchset exposes the device's PASID capability
> to guest instead of hiding it from guest.
> 
> The second patch emulates PASID capability for VFs (Virtual Function) since
> VFs don't implement such capability per PCIe spec. This patch emulates such
> capability and expose to VM if the capability is enabled in PF (Physical
> Function).
> 
> However, there is an open for PASID emulation. If PF driver disables PASID
> capability at runtime, then it may be an issue. e.g. PF should not disable
> PASID capability if there is guest using this capability on any VF related
> to this PF. To solve it, may need to introduce a generic communication
> framework between vfio-pci driver and PF drivers. Please feel free to give
> your suggestions on it.

I'm not sure how this is addressed on bate metal today, i.e. between normal 
kernel PF and VF drivers. I look at pasid enable/disable code in intel-iommu.c.
There is no check on PF/VF dependency so far. The cap is toggled when 
attaching/detaching the PF to its domain. Let's see how IOMMU guys 
respond, and if there is a way for VF driver to block PF driver from disabling
the pasid cap when it's being actively used by VF driver, then we may
leverage the same trick in VFIO when emulation is provided to guest.

Thanks
Kevin

> 
> Regards,
> Yi Liu
> 
> Changelog:
> 	- RFC v1 -> Patch v1:
> 	  Add CONFIG_PCI_ATS #ifdef control to avoid compiling error.
> 
> Liu Yi L (2):
>   vfio/pci: Expose PCIe PASID capability to guest
>   vfio/pci: Emulate PASID/PRI capability for VFs
> 
>  drivers/vfio/pci/vfio_pci_config.c | 327
> ++++++++++++++++++++++++++++++++++++-
>  1 file changed, 324 insertions(+), 3 deletions(-)
> 
> --
> 2.7.4

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2020-03-31  6:35 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
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 ` Tian, Kevin [this message]
2020-03-31  6:35   ` [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs 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=AADFC41AFE54684AB9EE6CBC0274A5D19D801252@SHSMSX104.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@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=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=jun.j.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: link
Be 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.