> From: Alex Williamson
> Sent: Tuesday, February 28, 2017 11:54 AM
>
> On Mon, 27 Feb 2017 19:54:41 +
> Jean-Philippe Brucker wrote:
>
[...]
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 3fe4197a5ea0..41ae8a231d42 100644
> > --- a/include/uapi/linux/vfio.h
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, March 01, 2017 6:07 AM
>
> On Wed, Nov 30, 2016 at 08:49:24AM +, Liu, Yi L wrote:
> > What's changed from v2:
> > a) Detailed feature description
> > b) refine description in "Address translation in virtual SVM"
>
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, February 28, 2017 11:23 PM
>
> Hi Kevin,
>
> On Tue, Feb 28, 2017 at 06:43:31AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Tuesday, February 28, 2017
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 28, 2017 3:55 AM
>
[...]
>
> API naming
> ==
>
> I realize that "SVM" as a name isn't great because the svm namespace is
> already taken by AMD-V (Secure Virtual Machine) in arch/x86. Also, the
> name itself doesn't say much.
>
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 12, 2017 9:22 PM
>
[...]
> By my limited understanding of VT-d details: The stolen memory is never
> directly accessed by i915 driver (because CPU access doesn't work even
> in DOM0). It is only used through
> From: Jason Wang
> Sent: Wednesday, April 12, 2017 5:07 PM
>
> On 2017年04月08日 03:17, Jean-Philippe Brucker wrote:
> > This is the initial proposal for a paravirtualized IOMMU device using
> > virtio transport. It contains a description of the device, a Linux driver,
> > and a toy implementation
> From: Jean-Philippe Brucker
> Sent: Saturday, April 8, 2017 3:18 AM
>
> This is the initial proposal for a paravirtualized IOMMU device using
> virtio transport. It contains a description of the device, a Linux driver,
> and a toy implementation in kvmtool. With this prototype, you can
> transla
> From: Jean-Philippe Brucker
> Sent: Saturday, April 8, 2017 3:18 AM
>
> Unlike other virtio devices, the virtio-iommu doesn't work independently,
> it is linked to other virtual or assigned devices. So before jumping into
> device operations, we need to define a way for the guest to discover the
> From: Jean-Philippe Brucker
> Sent: Saturday, April 8, 2017 3:18 AM
>
[...]
> II. Feature bits
>
>
> VIRTIO_IOMMU_F_INPUT_RANGE (0)
> Available range of virtual addresses is described in input_range
Usually only the maximum supported address bits are important.
Curious d
> From: Jean-Philippe Brucker
> Sent: Saturday, April 8, 2017 3:18 AM
>
> Here I propose a few ideas for extensions and optimizations. This is all
> very exploratory, feel free to correct mistakes and suggest more things.
[...]
>
> II. Page table sharing
> ==
>
> 1. Sh
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, April 19, 2017 2:41 AM
>
> On 18/04/17 10:51, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Saturday, April 8, 2017 3:18 AM
> >>
> >> Unlike oth
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, April 19, 2017 2:46 AM
>
> On 18/04/17 11:26, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Saturday, April 8, 2017 3:18 AM
> >
> From: Liu, Yi L [mailto:yi.l@linux.intel.com]
> Sent: Friday, May 19, 2017 1:24 PM
>
> Hi Alex,
>
> What's your opinion with Tianyu's question? Is it accepatable
> to use VFIO API in intel_iommu emulator?
Did you actually need such translation at all? SID should be
filled by kernel IOMMU d
> From: Liu, Yi L [mailto:yi.l@linux.intel.com]
> Sent: Sunday, May 14, 2017 6:55 PM
>
> On Fri, May 12, 2017 at 03:58:43PM -0600, Alex Williamson wrote:
> > On Wed, 26 Apr 2017 18:12:04 +0800
> > "Liu, Yi L" wrote:
> >
> > > From: "Liu, Yi L"
> > >
> > > This patch adds VFIO_IOMMU_TLB_INVAL
> From: Liu, Yi L
> Sent: Monday, July 3, 2017 6:31 PM
>
> Hi Jean,
>
>
> >
> > > 2. Define a structure in include/uapi/linux/iommu.h(newly added header
> file)
> > >
> > > struct iommu_tlb_invalidate {
> > > __u32 scope;
> > > /* pasid-selective invalidation described by @pasid */
> > > #de
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Wednesday, June 28, 2017 3:48 AM
>
> Add Intel VT-d ops to the generic iommu_bind_pasid_table API
> functions.
>
> The primary use case is for direct assignment of SVM capable
> device. Originated from emulated IOMMU in the guest, t
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, June 29, 2017 1:08 AM
>
> On 28/06/17 17:09, Jacob Pan wrote:
> > On Wed, 28 Jun 2017 12:08:23 +0200
> > Joerg Roedel wrote:
> >
> >> On Tue, Jun 27, 2017 at 12:47:57PM -0700, Jacob Pan wrote:
> >>> From: "Liu,
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, July 6, 2017 1:28 AM
>
> On Wed, 5 Jul 2017 13:42:03 +0100
> Jean-Philippe Brucker wrote:
>
> > On 05/07/17 07:45, Tian, Kevin wrote:
> > >> From: Liu, Yi L
> > >> Sen
> From: Jean-Philippe Brucker
> Sent: Wednesday, July 5, 2017 8:42 PM
>
> On 05/07/17 07:45, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Monday, July 3, 2017 6:31 PM
> >>
> >> Hi Jean,
> >>
> >>
> >>>
> >&g
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, October 20, 2018 2:12 AM
>
> This is a first prototype adding auxiliary domain support to Arm SMMUv3,
> following Lu Baolu's latest proposal for IOMMU aware mediated devices
> [1]. It works, but the attach() API
> From: Raj, Ashok
> Sent: Wednesday, October 24, 2018 1:17 AM
>
> >
> > But that's not reason enough to completely disable PASID for the
> > device,
> > it could be the only one bound to that process, or PASID could be
> > only
> > used privately by the host device driver.
>
> Agree, there could
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, October 23, 2018 2:57 PM
>
> Hi,
>
> On 10/22/18 6:22 PM, Raj, Ashok wrote:
> > On Mon, Oct 22, 2018 at 12:49:47PM +0800, Lu Baolu wrote:
> >> Hi,
> >>
> >> On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote:
> >>> Some devices mig
> From: Koenig, Christian
> Sent: Thursday, November 22, 2018 3:10 AM
>
> Am 21.11.18 um 12:16 schrieb Jean-Philippe Brucker:
> > On 12/11/2018 14:40, Joerg Roedel wrote:
> >> Hi Jean-Philippe,
> >>
> >> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote:
> >>> The allocator doe
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Monday, November 12, 2018 10:56 PM
>
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
> > (1) My initial approach would have been to use the same page tables for
> > the default_domain and this
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Friday, November 23, 2018 7:21 PM
>
> On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote:
> > Can you please elaborate a bit more about the concept of subdomains?
> > From my point of view, an aux-domain is a normal un-managed domain
>
> From: Tian, Kevin
> Sent: Monday, November 26, 2018 11:01 AM
[...]
> > aux-domain is just a normal domain (struct iommu_domain), what
> > happens
> > when a domain that was used as a primary domain and has bound
> > aux-domains to it, is bound with iommu_aux_domain_
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Friday, December 7, 2018 6:29 PM
>
> Hi,
>
> On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
> > btw Baolu just reminded me one thing which is worthy of noting here.
> > 'primar
> From: 'j...@8bytes.org'
> Sent: Monday, December 10, 2018 4:58 PM
>
> Hi Kevin,
>
> On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
> > Can I interpret above as that you agree with the aux domain concept (i.e.
> one
> > device can be link
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Wednesday, December 12, 2018 5:54 PM
>
> Hi Kevin,
>
> On Wed, Dec 12, 2018 at 09:31:27AM +, Tian, Kevin wrote:
> > > From: 'j...@8bytes.org'
> > > Sent: Monday, December 1
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of
> sathyanarayanan.kuppusw...@linux.intel.com
> Sent: Tuesday, February 12, 2019 5:51 AM
> To: bhelg...@google.com; j...@8bytes.org; dw...@infradead.org
> Cc: Raj, Ashok ; linux-...@vge
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Thursday, February 28, 2019 5:41 AM
>
> On Tue, 26 Feb 2019 12:17:43 +0100
> Joerg Roedel wrote:
>
> >
> > How about a 'struct iommu_sva' with an iommu-private definition that
> > is returned by this function:
> >
> > struct io
> From: Jean-Philippe Brucker
> Sent: Saturday, February 29, 2020 1:26 AM
>
> Platforms without device-tree do not currently have a method for
> describing the vIOMMU topology. Provide a topology description embedded
> into the virtio device.
>
> Use PCI FIXUP to probe the config space early, bec
> From: Jacob Pan
> Sent: Friday, March 27, 2020 12:45 AM
>
> Hi Christoph,
>
> Thanks for the review. Please see my comments inline.
>
> On Thu, 26 Mar 2020 02:23:16 -0700
> Christoph Hellwig wrote:
>
> > On Wed, Mar 25, 2020 at 04:17:05PM -0700, Jacob Pan wrote:
> > > Having a single UAPI v
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> IOASID is a limited system-wide resource that can be allocated at
> runtime. This limitation can be enumerated during boot. For example, on
> x86 platforms, PCI Process Address Space ID (PASID) allocation uses
> IOASID service. The nu
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> Assign system-wide PASID capacity with enumerated max value.
> Currently, all Intel SVM capable devices should support full 20 bits of
> PASID value.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-iommu.c | 4
> 1 fi
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> IOASID set defines a group of IDs that share the same token. The
> ioasid_set concept helps to do permission checking among users as in the
> current code.
>
> With guest SVA usage, each VM has its own IOASID set. More
> functionalit
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> IOASID set refers to a group of IOASIDs that shares the same token.
> ioasid_set_data() function is used to attach a private data to an IOASID,
> rename it to ioasid_attach_data() avoid being confused with the group/set
> concept.
>
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> Bare metal SVA allocates IOASIDs for native process addresses. This
> should be separated from VM allocated IOASIDs thus under its own set.
A curious question. Now bare metal SVA uses the system set and guest
SVA uses dynamically-cre
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> The current ioasid_alloc function takes a token/ioasid_set then record it
> on the IOASID being allocated. There is no alloc/free on the ioasid_set.
>
> With the IOASID set APIs, callers must allocate an ioasid_set before
> allocate
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> Each IOASID or set could have multiple users with its own HW context
> to maintain. Often times access to the HW context requires thread context.
> For example, consumers of IOASIDs can register notification blocks to
> sync up its st
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:55 AM
>
> IOASID users fit into the publisher-subscriber pattern, a system wide
> blocking notifier chain can be used to inform subscribers of state
> changes. Notifier mechanism also abstracts publisher from knowing the
> private context each
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:56 AM
>
> IOASID set is allocated with an initial quota, at runtime there may be
> needs to balance IOASID resources among different VMs/sets.
>
I may overlook previous patches but I didn't see any place setting the
initial quota...
> This p
> From: Jacob Pan
> Sent: Thursday, March 26, 2020 1:56 AM
>
> In bare metal SVA, IOMMU driver ensures that IOASID free call always comes
> after IOASID unbind operation.
>
> However, for guest SVA the unbind and free call come from user space
> via VFIO, which could be out of order. This patch r
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Move domain helper to header to be used by SVA code.
>
> Signed-off-by: Jacob Pan
> Reviewed-by: Eric Auger
> ---
> drivers/iommu/intel-iommu.c | 6 --
> include/linux/intel-iommu.h | 6 ++
> 2 files changed, 6 insertions(
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Memory type related flags can be grouped together for one simple check.
>
> ---
> v9 renamed from EMT to MTS since these are memory type support flags.
> ---
>
> Signed-off-by: Jacob Pan
> ---
> include/uapi/linux/iommu.h | 5
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Signed-off-by: Jacob Pan
could you elaborate in which scenario this helper function is required?
> ---
> drivers/iommu/intel-pasid.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/iommu/
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-pasid.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
> index 191508c7c03e..9
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
now the spec is already at rev3.1 😊
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 12:59 AM
>
> On Fri, 27 Mar 2020 08:38:44 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Thursday, March 26, 2020 1:55 AM
> > >
> > > IOASID set defines a grou
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 1:29 AM
>
> On Fri, 27 Mar 2020 09:41:55 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Thursday, March 26, 2020 1:55 AM
> > >
> > > Bare metal SVA allo
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 1:42 AM
>
> On Fri, 27 Mar 2020 09:54:11 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Thursday, March 26, 2020 1:55 AM
> > >
> > > The current ioasid_all
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 2:37 AM
>
> On Fri, 27 Mar 2020 10:03:26 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Thursday, March 26, 2020 1:55 AM
> > >
> > > IOASID users fit int
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 7:31 AM
>
> On Fri, 27 Mar 2020 10:09:04 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Thursday, March 26, 2020 1:56 AM
> > >
> > > IOASID set is allocat
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> When supporting guest SVA with emulated IOMMU, the guest PASID
> table is shadowed in VMM. Updates to guest vIOMMU PASID table
> will result in PASID cache flush which will be passed down to
> the host as bind guest PASID calls.
>
>
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate A
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> Virtual command registers are used in the guest only, to prevent
> vmexit cost, we cache the capability and store it during initialization.
>
> Signed-off-by: Jacob Pan
> Reviewed-by: Eric Auger
> Reviewed-by: Lu Baolu
>
> ---
>
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> From: Lu Baolu
>
> Enabling IOMMU in a guest requires communication with the host
> driver for certain aspects. Use of PASID ID to enable Shared Virtual
> Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
> provi
> From: Jacob Pan
> Sent: Saturday, March 21, 2020 7:28 AM
>
> When VT-d driver runs in the guest, PASID allocation must be
> performed via virtual command interface. This patch registers a
> custom IOASID allocator which takes precedence over the default
> XArray based allocator. The resulting I
> From: Jacob Pan
> Sent: Saturday, March 28, 2020 7:54 AM
>
> On Fri, 27 Mar 2020 00:47:02 -0700
> Christoph Hellwig wrote:
>
> > On Fri, Mar 27, 2020 at 02:49:55AM +, Tian, Kevin wrote:
> > > If those API calls are inter-dependent for composing a featu
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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 i
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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.
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 4:53 PM
>
> > 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
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 5:27 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
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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
> d
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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
>
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> 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).
are->is
> Also there are hardware assisted mediated pass-through solut
> From: Auger Eric
> Sent: Sunday, March 29, 2020 11:34 PM
>
> Hi,
>
> On 3/28/20 11:01 AM, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> When Shared Virtual Address (SVA) is enabled for a gue
> From: Auger Eric
> Sent: Monday, March 30, 2020 12:05 AM
>
> On 3/28/20 11:01 AM, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> When Shared Virtual Address (SVA) is enabled for a guest OS via
>
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 2:22 AM
>
> On Sun, 29 Mar 2020 16:03:36 +0800
> Lu Baolu wrote:
>
> > On 2020/3/27 20:21, Tian, Kevin wrote:
> > >> From: Jacob Pan
> > >> Sent: Saturday, March 21, 2020 7:28 AM
> > >
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 4:52 AM
>
> On Sat, 28 Mar 2020 08:02:01 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 21, 2020 7:28 AM
> > >
> > > When supporting guest SVA
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 10:37 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: Jacob Pan
> Sent: Tuesday, March 31, 2020 12:08 AM
>
> On Mon, 30 Mar 2020 05:40:40 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 28, 2020 7:54 AM
> > >
> > > On Fri, 27 Mar 2020 00:
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:33 PM
>
> 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
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:33 PM
>
> 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 o
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 11:55 PM
>
> On Tue, 31 Mar 2020 06:06:38 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Tuesday, March 31, 2020 12:08 AM
> > >
> > > On Mon, 30 Mar 2020 05:40:
> From: Liu, Yi L
> Sent: Tuesday, March 31, 2020 9:22 PM
>
> > 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_IOMM
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 2:14 AM
>
> On Sat, 28 Mar 2020 10:01:42 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 21, 2020 7:28 AM
> > >
> > > When Shared Virtual Addr
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 4:58 AM
>
> On Tue, 31 Mar 2020 02:49:21 +0000
> "Tian, Kevin" wrote:
>
> > > From: Auger Eric
> > > Sent: Sunday, March 29, 2020 11:34 PM
> > >
> > > Hi,
> > &g
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 5:08 AM
>
> On Tue, 31 Mar 2020 03:34:22 +0000
> "Tian, Kevin" wrote:
>
> > > From: Auger Eric
> > > Sent: Monday, March 30, 2020 12:05 AM
> > >
> > > On 3/28/20 11:01 AM, Tian
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 3:38 PM
>
> > 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
> &
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 4:07 PM
>
> > 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
> &
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 5:13 PM
>
> > 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
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 11:48 PM
>
> On Sat, 28 Mar 2020 10:22:41 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 21, 2020 7:28 AM
> > >
> > > When VT-d driver runs in
> From: Alex Williamson
> Sent: Friday, April 3, 2020 1:50 AM
>
> On Sun, 22 Mar 2020 05:31:58 -0700
> "Liu, Yi L" wrote:
>
> > 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
> From: Alex Williamson
> 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
> >
> > For VFIO IOMMUs with the type VFIO_TYPE1_NESTING_IOMMU, guest
> "owns" the
> > first-level/stage-1 translation structures, the host IOMMU drive
> From: Alex Williamson
> Sent: Saturday, April 4, 2020 1:26 AM
[...]
> > > > + if (!pasid_cap.control_reg.paside) {
> > > > + pr_debug("%s: its PF's PASID capability is not
> > > > enabled\n",
> > > > + dev_name(&vdev->pdev->dev));
> > > > +
> From: Alex Williamson
> Sent: Friday, April 3, 2020 11:14 PM
>
> On Fri, 3 Apr 2020 05:58:55 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Friday, April 3, 2020 1:50 AM
> > >
> > > On Sun, 22 Mar 2020
> From: Alex Williamson
> Sent: Saturday, April 4, 2020 1:50 AM
[...]
> > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > > index 9e843a1..298ac80 100644
> > > > --- a/include/uapi/linux/vfio.h
> > > > +++ b/include/uapi/linux/vfio.h
> > > > @@ -794,6 +794,47 @@ struct
> From: Alex Williamson
> Sent: Tuesday, April 7, 2020 11:58 PM
>
> On Tue, 7 Apr 2020 04:26:23 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Saturday, April 4, 2020 1:26 AM
> > [..
> From: Raj, Ashok
> Sent: Monday, April 13, 2020 11:11 AM
>
> On Wed, Apr 08, 2020 at 10:19:40AM -0600, Alex Williamson wrote:
> > On Tue, 7 Apr 2020 21:00:21 -0700
> > "Raj, Ashok" wrote:
> >
> > > Hi Alex
> > >
> > > + Bjorn
> >
> > + Don
> >
> > > FWIW I can't understand why PCI SIG went di
> From: Tian, Kevin
> Sent: Monday, April 13, 2020 3:55 PM
>
> > From: Raj, Ashok
> > Sent: Monday, April 13, 2020 11:11 AM
> >
> > On Wed, Apr 08, 2020 at 10:19:40AM -0600, Alex Williamson wrote:
> > > On Tue, 7 Apr 2020 21:00:21 -0700
> &
> From: Alex Williamson
> Sent: Tuesday, April 14, 2020 3:21 AM
>
> On Mon, 13 Apr 2020 08:05:33 +0000
> "Tian, Kevin" wrote:
>
> > > From: Tian, Kevin
> > > Sent: Monday, April 13, 2020 3:55 PM
> > >
> > > > From: Raj, Asho
> From: Alex Williamson
> Sent: Tuesday, April 14, 2020 11:29 AM
>
> On Tue, 14 Apr 2020 02:40:58 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 14, 2020 3:21 AM
> > >
> > &g
> From: Jacob Pan
> Sent: Wednesday, April 15, 2020 6:32 AM
>
> On Tue, 14 Apr 2020 10:13:04 -0700
> Jacob Pan wrote:
>
> > > > > In any of the proposed solutions, the
> > > > > IOMMU driver is ultimately responsible for validating the user
> > > > > data, so do we want vfio performing the cop
> From: Alex Williamson
> Sent: Tuesday, April 14, 2020 11:24 PM
>
> On Tue, 14 Apr 2020 03:42:42 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 14, 2020 11:29 AM
> > >
> > &g
> From: Alex Williamson
> Sent: Wednesday, April 15, 2020 8:36 AM
>
> On Tue, 14 Apr 2020 23:57:33 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 14, 2020 11:24 PM
> > >
> > &g
> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 1:26 PM
>
> When a PASID is stopped or terminated, there can be pending PRQs
> (requests that haven't received responses) in the software and
> remapping hardware. The pending page requests must be drained
> so that the pasid could be reused. The
> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 1:26 PM
>
> Current qi_submit_sync() supports single invalidation descriptor
> per submission and appends wait descriptor after each submission
> to poll hardware completion. This patch adjusts the parameters
> of this function so that multiple d
1 - 100 of 784 matches
Mail list logo
