Hi Jean, Eric,
> From: Liu, Yi L
> Sent: Thursday, April 9, 2020 8:47 PM
> Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
[...]
> > > >>
> > > >> Yes I don't think an u32 is going to cut it for
Hi Eric,
> From: Auger Eric
> Sent: Friday, April 10, 2020 11:28 AM
> To: Liu, Yi L ; Jean-Philippe Brucker Subject: Re: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> Hi Yi,
>
> On 4/9/20 2:47 PM, Liu, Yi L wrote:
> > Hi Jean
Hi Jean,
> From: Jean-Philippe Brucker
> Sent: Thursday, April 9, 2020 4:15 PM
> Subject: Re: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> On Wed, Apr 08, 2020 at 12:27:58PM +0200, Auger Eric wrote:
> > Hi Yi,
> >
> >
> From: Jean-Philippe Brucker
> Sent: Thursday, April 9, 2020 4:29 PM
> To: Liu, Yi L
>
> On Tue, Apr 07, 2020 at 10:33:25AM +, Liu, Yi L wrote:
> > Hi Jean,
> >
> > > From: Jean-Philippe Brucker < jean-phili...@linaro.org >
> > > Se
gt; > > Sent: Friday, April 3, 2020 4:24 AM
> > >
> > > On Sun, 22 Mar 2020 05:32:04 -0700
> > > "Liu, Yi L" wrote:
> > >
> > > > From: Liu Yi L
> > > >
[...]
>
> > >
> > &
> From: Liu, Yi L
> Sent: Tuesday, April 7, 2020 5:43 PM
>
> > We don't, the PASID spaces are per-VM on Arm, so this function should
> > consult the IOMMU driver before setting flags. As you said on patch 3,
> > nested doesn't necessarily imply PASID support. The SMMUv2
Hi Alex,
> From: Alex Williamson
> Sent: Saturday, April 4, 2020 1:50 AM
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Fri, 3 Apr 2020 13:12:50 +0000
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> >
> > > From:
Hi Jean,
> From: Jean-Philippe Brucker < jean-phili...@linaro.org >
> Sent: Friday, April 3, 2020 4:35 PM
> Subject: Re: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
>
> On Thu, Apr 02, 2020 at 08:05:29AM +, Liu, Yi L wrote:
> > > > > >
Hi Jean,
> From: Jean-Philippe Brucker
> Sent: Friday, April 3, 2020 4:23 PM
> To: Auger Eric
> userspace
>
> On Wed, Apr 01, 2020 at 03:01:12PM +0200, Auger Eric wrote:
> > >>> header = vfio_info_cap_add(caps, sizeof(*nesting_cap),
> > >>>
Hi Eric,
> From: Auger Eric
> Sent: Wednesday, April 1, 2020 9:31 PM
> To: Liu, Yi L ; eric.auger@gmail.com;
> iommu@lists.linux-
> Subject: Re: [PATCH v10 04/11] vfio/pci: Add VFIO_REGION_TYPE_NESTED region
> type
>
> Hi Yi,
>
> On 4/1/20 3:18 PM
Hi Alex,
> From: Alex Williamson
> Sent: Saturday, April 4, 2020 1:28 AM
> To: Liu, Yi L
> Cc: eric.au...@redhat.com; Tian, Kevin ;
> jacob.jun@linux.intel.com; j...@8bytes.org; Raj, Ashok
> ;
> Tian, Jun J ; Sun, Yi Y ; jean-
> phili...@linaro.org; pet...@redha
Hi Alex,
> From: Alex Williamson
> Sent: Saturday, April 4, 2020 2:11 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
>
> On Fri, 3 Apr 2020 13:30:49 +
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> >
&
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 4:34 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 8/8] vfio/type1: Add vSVA support for IOMMU-backed
> mdevs
>
> On Sun, 22 Mar 2020 05:32:05 -0700
> "Liu, Yi L" wrote:
>
> > From: Liu
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 3:57 AM
> To: Liu, Yi L
>
> On Sun, 22 Mar 2020 05:32:03 -0700
> "Liu, Yi L" wrote:
>
> > From: Liu Yi L
> >
> > VFIO_TYPE1_NESTING_IOMMU is an IOMMU type which is backed by hard
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 1:50 AM
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Sun, 22 Mar 2020 05:31:58 -0700
> "Liu, Yi L" wrote:
>
> > From: Liu Yi L
> >
> > F
> From: Jean-Philippe Brucker
> Sent: Friday, April 3, 2020 8:40 PM
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Fri, Apr 03, 2020 at 11:56:09AM +, Liu, Yi L wrote:
> > > > /**
> > > > + * VFIO_MM obje
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 3:20 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> On Sun, 22 Mar 2020 05:32:02 -0700
> "Liu, Yi L" wrote:
>
> > From: L
Hi Jean,
> From: Jean-Philippe Brucker
> Sent: Thursday, April 2, 2020 9:53 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> Hi Yi,
>
> On Sun, Mar 22, 2020 at 05:31:58AM -0700, Liu, Yi L wrote:
> > From: Liu
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 7:00 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs
>
> On Sun, 22 Mar 2020 05:33:14 -0700
> "Liu, Yi L" wrote:
>
> > From: Liu Yi L
>
> From: Alex Williamson < alex.william...@redhat.com >
> Sent: Friday, April 3, 2020 2:01 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 3/8] vfio/type1: Report PASID alloc/free support to
> userspace
>
> On Sun, 22 Mar 2020 05:32:00 -0700
> "Liu,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 1:59 AM
> To: Tian, Kevin
> Subject: Re: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter for
> quota
> tuning
>
> On Mon, 30 Mar 2020 11:44:08 +
> "Tian, Kevin" wrote:
>
> > &
Hi Alex,
> From: Alex Williamson
> Sent: Friday, April 3, 2020 7:00 AM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs
>
> On Sun, 22 Mar 2020 05:33:14 -0700
> "Liu, Yi L" wrote:
>
> > From: Liu Yi L
>
> From: Tian, Kevin
> Sent: Thursday, April 2, 2020 10:12 AM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
>
> > From: Liu, Yi L
> > Sent: Wednesday, April 1, 2020 5:13 PM
> >
> >
om; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; k...@vger.kernel.org;
> kvm...@lists.cs.columbia.edu; j...@8bytes.org; alex.william...@redhat.com;
> jacob.jun@linux.intel.com; Liu, Yi L ; jean-
> philippe.bruc...@arm.com; will.dea...@arm.com; robin.mur...@ar
Hi Eric,
> From: Auger Eric
> Sent: Wednesday, April 1, 2020 5:41 PM
> To: Liu, Yi L ; alex.william...@redhat.com
> Subject: Re: [PATCH v1 3/8] vfio/type1: Report PASID alloc/free support to
> userspace
>
> Yi,
> On 3/22/20 1:32 PM, Liu, Yi L wrote:
> > From
Hi Eric,
> From: Auger Eric
> Sent: Wednesday, April 1, 2020 4:51 PM
> To: Liu, Yi L ; alex.william...@redhat.com
> Subject: Re: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> Hi Yi,
> On 3/22/20 1:32 PM, Liu, Yi L wrote:
> > From:
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 8:46 PM
> Subject: RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > VFIO_TYPE
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 4:09 PM
> Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> > From: Liu, Yi L
> > Sent: Wednesday, April 1, 2020 4:07 PM
> >
> > > From: Tian, Kevin
&g
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 3:56 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> > From: Liu, Yi L
> > Sent: Wednesday, April 1, 2020 3:38 P
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 9:19 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 8/8] vfio/type1: Add vSVA support for IOMMU-backed
> mdevs
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 8:58 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 7/8] vfio/type1: Add VFIO_IOMMU_CACHE_INVALIDATE
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> >
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 5:44 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 3/8] vfio/type1: Report PASID alloc/free support to
> userspace
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 7:49 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> &
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 2:30 PM
> To: Jacob Pan
> Subject: RE: [PATCH V10 08/11] iommu/vt-d: Add svm/sva invalidate function
>
> > From: Jacob Pan
> > Sent: Wednesday, April 1, 2020 4:58 AM
> >
> > On Tue, 31 Mar 2020 02:49:21 +
> > "Tian, Kevin" wrote:
> >
>
guest to the physical IOMMU.
> > > >
> > > > The assumption is that guest to host device ID mapping should be
> > > > resolved prior to calling IOMMU driver. Based on the device handle,
> > > > host IOMMU driver can replace certain fields before submit to the
&g
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 1:43 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Liu, Yi L
> > Sent: Tuesday, March 31, 2020 9:22 PM
> >
&g
> From: Tian, Kevin
> Sent: Tuesday, March 31, 2020 1:41 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> eric.au...@redhat.com
> Subject: RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Liu, Yi L
> > Sent: Monday, March 30, 2020
Hi Hellwig,
Thanks for your review, Hellwig. :-) inline reply.
> From: Christoph Hellwig
> Sent: Tuesday, March 31, 2020 3:56 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 7/8] vfio/type1: Add VFIO_IOMMU_CACHE_INVALIDATE
>
> > @@ -2629,6 +2638,46 @@ static long vfio_i
> From: Liu, Yi L
> Sent: Tuesday, March 31, 2020 4:33 PM
> To: 'Christoph Hellwig'
> Subject: RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Christoph Hellwig
> > Sent: Tuesday, March 31, 2020 3:54 PM
> > To: Liu, Yi L
> >
> From: Christoph Hellwig
> Sent: Tuesday, March 31, 2020 3:54 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> Who is going to use thse exports? Please submit them together with
> a driver actually using them.
Hi Hel
> From: Christoph Hellwig
> Sent: Tuesday, March 31, 2020 3:54 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> Who is going to use thse exports? Please submit them together with
> a driver actually using them.
Hi Hellwi
> From: Tian, Kevin
> Sent: Tuesday, March 31, 2020 2:39 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 1/2] vfio/pci: Expose PCIe PASID capability to guest
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:33 PM
> >
>
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 4:32 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> >
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 5:20 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter for
> quota
> tuning
>
> > From: Liu, Yi L
> > Sent: Monday, March 30, 2020 4:
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 4:41 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter for
> quota
> tuning
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 20
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
> To: alex.william...@redhat.com; eric.au...@redhat.com
> Subject: [PATCH v1 0/8] vfio: expose virtual Shared Virtual Addressing to VMs
>
> From: Liu Yi L
>
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual
From: Liu Yi L
This patch exposes PCIe PASID capability to guest. Existing vfio_pci
driver hides it from guest by setting the capability length as 0 in
pci_ext_cap_length[].
This capability is required for vSVA enabling on pass-through PCIe
devices.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex
From: Liu Yi L
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
From: Liu Yi L
Per PCIe r5.0, sec 9.3.7.14, if a PF implements the PASID Capability, the
PF PASID configuration is shared by its VFs. VFs must not implement their
own PASID Capability.
Per PCIe r5.0, sec 9.3.7.11, VFs must not implement the PRI Capability. If
the PF implements PRI
From: Liu Yi L
This patch reports PASID alloc/free availability to userspace (e.g. QEMU)
thus userspace could do a pre-check before utilizing this feature.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Signed-off-by: Liu Yi L
---
drivers/vfio
From: Liu Yi L
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.
This VFIO series is intended to expose SVA usage to VMs. i.e
From: Liu Yi L
This patch adds a module option to make the PASID quota tunable by
administrator.
TODO: needs to think more on how to make the tuning to be per-process.
Previous discussions:
https://patchwork.kernel.org/patch/11209429/
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc
From: Liu Yi L
VFIO exposes IOMMU nesting translation (a.k.a dual stage translation)
capability to userspace. Thus applications like QEMU could support
vIOMMU with hardware's nesting translation capability for pass-through
devices. Before setting up nesting translation for pass-through devices
From: Liu Yi L
Recent years, mediated device pass-through framework (e.g. vfio-mdev)
are used to achieve flexible device sharing across domains (e.g. VMs).
Also there are hardware assisted mediated pass-through solutions from
platform vendors. e.g. Intel VT-d scalable mode which supports Intel
From: Liu Yi L
For a long time, devices have only one DMA address space from platform
IOMMU's point of view. This is true for both bare metal and directed-
access in virtualization environment. Reason is the source ID of DMA in
PCIe are BDF (bus/dev/fnc ID), which results in only device
From: Liu Yi L
VFIO_TYPE1_NESTING_IOMMU is an IOMMU type which is backed by hardware
IOMMUs that have nesting DMA translation (a.k.a dual stage address
translation). For such hardware IOMMUs, there are two stages/levels of
address translation, and software may let userspace/VM to own the first
From: Liu Yi L
For VFIO IOMMUs with the type VFIO_TYPE1_NESTING_IOMMU, guest "owns" the
first-level/stage-1 translation structures, the host IOMMU driver has no
knowledge of first-level/stage-1 structure cache updates unless the guest
invalidation requests are trapped and propagated t
From: Liu Yi L
In Linux Kernel, the IOMMU nesting translation (a.k.a dual stage address
translation) capability is abstracted in uapi/iommu.h, in which the uAPIs
like bind_gpasid/iommu_cache_invalidate/fault_report/pgreq_resp are defined.
VFIO_TYPE1_NESTING_IOMMU stands for the vfio iommu type
e invalidation queue.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Ashok Raj
> Signed-off-by: Liu, Yi L
May be update my email to Liu Yi L :-) @linux.intel.com
account no more work for me. :-(
> ---
> drivers/iommu/intel-iommu.c | 173
> +++
> From: Liu, Yi L
> Sent: Friday, January 31, 2020 8:41 PM
> To: Alex Williamson
> Subject: RE: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
> > > +static int vfio_iommu_type1_pasid_free(struct vfio_iommu *iommu,
> > > +
Hi Jacob,
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Saturday, February 8, 2020 3:44 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 2/8] vfio/type1: Make per-application (VM) PASID quota
> tunable
>
> On Wed, 29 Jan 2020 04:11:46 -0800
> "Liu, Yi L
Hi Alex,
Any comment on this series?
Regards,
Yi Liu
> From: Liu, Yi L
> Sent: Wednesday, January 29, 2020 8:19 PM
> To: alex.william...@redhat.com; eric.au...@redhat.com
> Subject: [RFC v1 0/2] vfio/pci: expose device's PASID capability to VMs
>
> Shared Virtual Addre
> From: Liu, Yi L
> Sent: Friday, January 31, 2020 8:41 PM
> To: Alex Williamson
> Subject: RE: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> Hi Alex,
>
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, January
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 30, 2020 7:57 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 2/8] vfio/type1: Make per-application (VM) PASID quota
> tunable
>
> On Wed, 29 Jan 2020 04:11:46 -0800
> "Liu, Yi L&q
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, February 4, 2020 2:01 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 4/8] vfio/type1: Add
> VFIO_NESTING_GET_IOMMU_UAPI_VERSION
>
> On Fri, 31 Jan 2020 13:04:11 +
> "Liu, Yi L" wro
Hi Alex,
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 30, 2020 7:57 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 4/8] vfio/type1: Add
> VFIO_NESTING_GET_IOMMU_UAPI_VERSION
>
> On Wed, 29 Jan 2020 04:11:48 -0800
> "Liu, Yi L&q
Hi Alex,
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 30, 2020 7:57 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 3/8] vfio: Reclaim PASIDs when application is down
>
> On Wed, 29 Jan 2020 04:11:47 -0800
> "Liu, Yi L"
Hi Alex,
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 30, 2020 7:56 AM
> To: Liu, Yi L
> Subject: Re: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Wed, 29 Jan 2020 04:11:45 -0800
> "Liu, Yi L"
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Wednesday, January 29, 2020 2:02 PM
> Subject: [PATCH V9 00/10] Nested Shared Virtual Address (SVA) VT-d support
>
> Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
> platforms
> allow address space
From: Liu Yi L
This patch exposes PCIe PASID capability to guest. Existing vfio_pci
driver hides it from guest by setting the capability length as 0 in
pci_ext_cap_length[].
This capability is required for vSVA enabling on pass-through PCIe
devices.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex
From: Liu Yi L
Per PCIe r5.0, sec 9.3.7.14, if a PF implements the PASID Capability, the
PF PASID configuration is shared by its VFs. VFs must not implement their
own PASID Capability.
Per PCIe r5.0, sec 9.3.7.11, VFs must not implement the PRI Capability. If
the PF implements PRI
to introduce a generic communication
framework between vfio-pci driver and PF drivers. Please feel free to give
your suggestions on it.
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 | 321
From: Liu Yi L
When userspace application is down, kernel should reclaim the PASIDs
allocated for this application to avoid PASID leak. This patch adds
a PASID list in vfio_mm structure to track the allocated PASIDs. The
PASID reclaim will be triggered when last vfio container is released
From: Liu Yi L
The PASID quota is per-application (VM) according to vfio's PASID
management rule. For better flexibility, quota shall be user tunable
. This patch provides a VFIO based user interface for which quota can
be adjusted. However, quota cannot be adjusted downward below the
number
From: Liu Yi L
For IOMMU with type VFIO_TYPE1_NESTING_IOMMU, guest "owns" the
first-level/stage-1 translation structures, the host IOMMU driver
has no knowledge of first-level/stage-1 structure cache updates
unless the guest invalidation requests are trapped and passed down
t
From: Liu Yi L
Recent years, mediated device pass-through framework (e.g. vfio-mdev)
are used to achieve flexible device sharing across domains (e.g. VMs).
Also there are hardware assisted mediated pass-through solutions from
platform vendors. e.g. Intel VT-d scalable mode which supports Intel
RFC v1 -> v2:
Dropped vfio: VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE.
Liu Yi L (8):
vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
vfio/type1: Make per-application (VM) PASID quota tunable
vfio: Reclaim PASIDs when application is down
vfio/type1: Add VFIO_NESTING_GET_IOMMU_UAP
From: Liu Yi L
For a long time, devices have only one DMA address space from platform
IOMMU's point of view. This is true for both bare metal and directed-
access in virtualization environment. Reason is the source ID of DMA in
PCIe are BDF (bus/dev/fnc ID), which results in only device
From: Liu Yi L
In Linux Kernel, the IOMMU nesting translation (a.k.a. IOMMU dual stage
translation capability) is abstracted in uapi/iommu.h, in which the uAPIs
like bind_gpasid/iommu_cache_invalidate/fault_report/pgreq_resp are defined.
VFIO_TYPE1_NESTING_IOMMU stands for the vfio iommu type
From: Liu Yi L
VFIO exposes IOMMU nesting translation (a.k.a dual stage translation)
capability to userspace. Thus applications like QEMU could support
vIOMMU with hardware's nesting translation capability for pass-through
devices. Before setting up nesting translation for pass-through devices
From: Liu Yi L
VFIO_TYPE1_NESTING_IOMMU is an IOMMU type which stands for hardware
IOMMUs that have nesting DMA translation (a.k.a dual stage address
translation). For such IOMMUs, there are two stages/levels of address
translation, and software may let userspace/VM to own the first-level/
stage
> From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of ???
> Sent: Saturday, January 18, 2020 12:21 PM
> To: iommu@lists.linux-foundation.org
> Subject: intel iommu pasid question
>
> Hi all，
>
>
> I am currently developing a pcie device driver on Linux kernel 4.4 or
gt; '-----------'
> >
> > This patch applies the first level page table for IOVA translation
> > unless the DOMAIN_ATTR_NESTING domain attribution has been set.
> > Setting of this attribution means the second level will be used to map
> > gPA (guest physical addr
t; Setting of this attribution means the second level will be used to
> map gPA (guest physical address) to hPA (host physical address), and
> the mappings between gVA (guest virtual address) and gPA will be
> maintained by the guest with the page table address binding to host's
> first level.
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, December 19, 2019 11:17 AM
> To: Joerg Roedel ; David Woodhouse ;
> Alex Williamson
> Subject: [PATCH v4 4/7] iommu/vt-d: Setup pasid entries for iova over first
> level
>
> Intel VT-d in scalable mode supports two types of
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, December 17, 2019 9:39 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
>
> From: Liu, Yi L
> Sent: Tuesday, December 17, 2019 10:26 AM
> To: Lu Baolu ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: RE: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
> > From: Lu Baolu [mailto:b
> From: Lu Baolu < baolu...@linux.intel.com >
> Sent: Tuesday, December 17, 2019 10:04 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 4/6] iommu/vt-d: Setup pasid entries for iova over
> first level
>
> Hi Yi,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, December 17, 2019 9:37 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first
> level
>
>
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Saturday, December 14, 2019 11:04 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 4/6] iommu/vt-d: Setup pasid entries for iova over
> first level
>
Hi Baolu,
Please check replies below:
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Saturday, December 14, 2019 11:24 AM
> To: Liu, Yi L ; Joerg Roedel ; David
> Woodhouse ; Alex Williamson
>
> Subject: Re: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for
Hi Allen,
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Lu Baolu
> Sent: Wednesday, December 11, 2019 10:12 AM
> To: Joerg Roedel ; David Woodhouse ;
> Subject: [PATCH v3 5/6] iommu/vt-d: Flush PASID-based iotlb for iova over
> first level
>
> When software
Hi Allen,
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Lu Baolu
> Sent: Wednesday, December 11, 2019 10:12 AM
> Subject: [PATCH v3 4/6] iommu/vt-d: Setup pasid entries for iova over first
> level
>
> Intel VT-d in scalable mode supports two types of page
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, December 3, 2019 8:12 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to
> host
>
> On Mon, 25 Nov 2019 07:45:18 +
> "Liu,
and scaled per
assigned device number. If no apparent issue, we may prepare a version
to see if it is workable.
Thanks,
Yi Liu
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Thursday, November 14, 2019 3:45 AM
> To: Alex Williamson
> Cc: Liu, Yi L ; eric.au...@redhat.com;
rom: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: Wednesday, November 13, 2019 6:29 PM
> To: Liu, Yi L
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to
> host
>
> On Wed, Nov 13, 2019 at 07:43:43AM +, Liu, Yi L wrote:
> &
> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: Wednesday, November 13, 2019 6:29 PM
> To: Liu, Yi L
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to
> host
>
> On Wed, Nov 13, 2019 at 07:43:43AM +, Liu, Yi L wr
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 8, 2019 11:15 PM
> To: Liu, Yi L
> Subject: Re: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Fri, 8 Nov 2019 12:23:41 +
> "Liu, Yi L" wrote:
> From: Alex Williamson
> Sent: Wednesday, November 13, 2019 1:26 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to
> host
>
> On Tue, 12 Nov 2019 11:21:40 +
> "Liu, Yi L" wrote:
>
> > > From
> From: Alex Williamson < alex.william...@redhat.com >
> Sent: Friday, November 8, 2019 7:21 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to
> host
>
> On Thu, 24 Oct 2019 08:26:23 -0400
> Liu Yi L wrote:
>
301 - 400 of 538 matches
Mail list logo
