> 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
> 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 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 A
> 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: 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:
>
> 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
>
> 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
> 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: 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
>
> 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
>
> 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
>
> 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
> 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
>
> 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
> 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: Jacob Pan
> Sent: Wednesday, April 22, 2020 2:53 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: Wednesday, April 22, 2020 2:53 AM
>
> An Intel iommu domain uses 5-level page table by default. If the
> iommu that the domain tries to attach supports less page levels,
> the top level page tables should be skipped. Add a helper to do
> this so that it could be used in
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> Current qi_submit_sync() only supports single invalidation descriptor
> per submission and appends wait descriptor after each submission to
> poll the hardware completion. This extends the qi_submit_sync() helper
> to support multiple
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> When a PASID is used for SVA by the device, it's possible that the PASID
> entry is cleared before the device flushes all ongoing DMA requests. The
> IOMMU should ignore the non-recoverable faults caused by these requests.
> Intel VT-d
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> When a PASID is stopped or terminated, there can be pending PRQs
> (requests that haven't received responses) in remapping hardware.
> This adds the interface to drain page requests and call it when a
> PASID is terminated.
>
>
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:55 AM
>
> 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: Thursday, May 7, 2020 8:56 AM
>
> IOTLB flush already included in the PASID tear down and the page request
> drain process. There is no need to flush again.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-svm.c | 6 +-
> 1 file
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> Export invalidation queue internals of each iommu device through the
> debugfs.
>
> Example of such dump on a Skylake machine:
>
> $ sudo cat /sys/kernel/debug/iommu/intel/invalidation_queue
> Invalidation queue on IOMMU: dmar1
>
> From: Alex Williamson
> Sent: Saturday, May 16, 2020 1:59 AM
>
> On Fri, 15 May 2020 07:39:14 +0000
> "Tian, Kevin" wrote:
>
> > Hi, Alex,
> >
> > When working on an updated version Yi and I found an design open
> > which needs your
> From: Raj, Ashok
> Sent: Friday, May 15, 2020 11:20 PM
>
> On Fri, May 15, 2020 at 12:39:14AM -0700, Tian, Kevin wrote:
> > Hi, Alex,
> >
> > When working on an updated version Yi and I found an design open
> > which needs your guidance.
> >
> >
sting is used. Do you think
whether such tradeoff is acceptable as a starting point?
Thanks
Kevin
> -Original Message-
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
> To: alex.william...@redhat.com; eric.au...@redhat.com
> Cc: Tian, Kevin ; jacob.jun@lin
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 9:23 PM
>
> Hi Kevin,
>
> On 2020/5/7 13:45, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Thursday, May 7, 2020 8:56 AM
> >>
> >> When a PASID is used for SVA by the device, it's possible
> From: Lu Baolu
> Sent: Friday, September 4, 2020 9:03 AM
>
> If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
> table, we could default to the device NUMA domain as fall back. This could
> also benefit a vIOMMU use case where only single vIOMMU is exposed,
> hence
> no
> From: Jason Gunthorpe
> Sent: Tuesday, September 15, 2020 10:29 PM
>
> > Do they need a device at all? It's not clear to me why RID based
> > IOMMU management fits within vfio's scope, but PASID based does not.
>
> In RID mode vfio-pci completely owns the PCI function, so it is more
> natural
> From: Jason Wang
> Sent: Monday, September 14, 2020 12:20 PM
>
> On 2020/9/10 下午6:45, Liu Yi L wrote:
> > 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
> From: Jason Wang
> Sent: Monday, September 14, 2020 4:57 PM
>
> On 2020/9/14 下午4:01, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Monday, September 14, 2020 12:20 PM
> >>
> >> On 2020/9/10 下午6:45, Liu Yi L wrote:
> >>> Shared
> From: Jason Wang
> Sent: Thursday, October 15, 2020 2:52 PM
>
>
> On 2020/10/14 上午11:08, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Tuesday, October 13, 2020 2:22 PM
> >>
> >>
> >> On 2020/10/12 下午4:38, Tian, Kevin wrote
with this
separation.
Please let us know your thoughts.
Thanks
Kevin
> From: Tian, Kevin
> Sent: Monday, October 12, 2020 4:39 PM
>
> > From: Jason Wang
> > Sent: Monday, September 14, 2020 12:20 PM
> >
> [...]
> > If it's possible, I would suggest a generic uAP
> From: Jason Wang
> Sent: Tuesday, October 13, 2020 2:22 PM
>
>
> On 2020/10/12 下午4:38, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Monday, September 14, 2020 12:20 PM
> >>
> > [...]
> > > If it's possible, I would s
> From: Jean-Philippe Brucker
> Sent: Tuesday, October 13, 2020 6:28 PM
>
> On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > > From: Jason Wang
> > > Sent: Monday, September 14, 2020 12:20 PM
> > >
> > [...]
> > > If
> From: Jason Wang
> Sent: Monday, September 14, 2020 12:20 PM
>
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
> specific one.
>
> Jason suggest something like /dev/sva. There will be a lot of other
> subsystems that could benefit from this (e.g vDPA).
>
> Have you
> From: Lu Baolu
> Sent: Wednesday, August 26, 2020 10:58 AM
>
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
>
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple
> From: Lu Baolu
> Sent: Thursday, August 27, 2020 12:25 PM
>
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
>
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple
> From: Lu Baolu
> Sent: Friday, August 28, 2020 8:06 AM
>
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
>
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple writes
> From: Lu Baolu
> Sent: Thursday, August 27, 2020 1:57 PM
>
> If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
> table, we could default to the device NUMA domain as fall back. This also
> benefits the vIOMMU use case where only a single vIOMMU is exposed,
> hence
> no
> From: Jason Gunthorpe
> Sent: Wednesday, September 16, 2020 10:45 PM
>
> On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, September 15, 2020 10:29 PM
> > >
> > > > Do they need a
> From: Xiang Zheng
> Sent: Monday, May 25, 2020 7:34 PM
>
> [+cc Kirti, Yan, Alex]
>
> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> > Hi,
> >
> > On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
> >> Hi all,
> >>
> >> Is there any plan for enabling SMMU HTTU?
> >
> > Not
> From: Xiang Zheng
> Sent: Wednesday, May 27, 2020 2:45 PM
>
>
> On 2020/5/27 11:27, Tian, Kevin wrote:
> >> From: Xiang Zheng
> >> Sent: Monday, May 25, 2020 7:34 PM
> >>
> >> [+cc Kirti, Yan, Alex]
> >>
> >> On 2020/5/23 1:
> From: Alex Williamson
> Sent: Thursday, July 30, 2020 4:25 AM
>
> On Tue, 14 Jul 2020 13:57:02 +0800
> Lu Baolu wrote:
>
> > The device driver needs an API to get its aux-domain. A typical usage
> > scenario is:
> >
> > unsigned long pasid;
> > struct iommu_domain *domain;
>
> From: Alex Williamson
> Sent: Thursday, July 30, 2020 4:04 AM
>
> On Thu, 16 Jul 2020 09:07:46 +0800
> Lu Baolu wrote:
>
> > Hi Jacob,
> >
> > On 7/16/20 12:01 AM, Jacob Pan wrote:
> > > On Wed, 15 Jul 2020 08:47:36 +0800
> > > Lu Baolu wrote:
> > >
> > >> Hi Jacob,
> > >>
> > >> On 7/15/20
> From: Liu, Yi L
> Sent: Saturday, June 27, 2020 2:53 PM
>
> Hi Robin,
>
> > From: Robin Murphy
> > Sent: Saturday, June 27, 2020 12:05 AM
> >
> > On 2020-06-26 08:47, Jean-Philippe Brucker wrote:
> > > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > >> IOMMUs that support
> From: Jacob Pan
> Sent: Tuesday, June 30, 2020 7:05 AM
>
> On Fri, 26 Jun 2020 16:19:23 -0600
> Alex Williamson wrote:
>
> > On Tue, 23 Jun 2020 10:03:53 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support communications between
> > > guest virtual IOMMU and host
> From: Lu Baolu
> Sent: Sunday, June 28, 2020 8:34 AM
>
> After a page request is handled, software must response the device which
> raised the page request with the handling result. This is done through
> the iommu ops.page_response if the request was reported to outside of
> vendor iommu
> From: Lu Baolu
> Sent: Thursday, June 25, 2020 3:26 PM
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > DevTLB flush can be used for both DMA request with and without PASIDs.
> > The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
> > usage.
> >
> > This patch adds a check for
> From: Liu, Yi L
> Sent: Monday, June 29, 2020 8:23 PM
>
> Hi Stefan,
>
> > From: Stefan Hajnoczi
> > Sent: Monday, June 29, 2020 5:25 PM
> >
> > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > > +/*
> > > + * struct iommu_nesting_info - Information for nesting-capable IOMMU.
>
> From: Lu Baolu
> Sent: Monday, July 6, 2020 8:26 AM
>
> It is refactored in two ways:
>
> - Make it global so that it could be used in other files.
>
> - Make bus/devfn optional so that callers could ignore these two returned
> values when they only want to get the coresponding iommu
> From: Lu Baolu
> Sent: Monday, July 6, 2020 8:26 AM
>
> After a page request is handled, software must response the device which
> raised the page request with the handling result. This is done through
'response' is a noun.
> the iommu ops.page_response if the request was reported to outside
> From: Tian, Kevin
> Sent: Monday, July 6, 2020 9:30 AM
>
> > From: Lu Baolu
> > Sent: Monday, July 6, 2020 8:26 AM
> >
> > A pasid might be bound to a page table from a VM guest via the iommu
> > ops.sva_bind_gpasid. In this case, when a DMA page fault is
> From: Lu Baolu
> Sent: Monday, July 6, 2020 8:26 AM
>
> There are several places in the code that need to get the pointers of
> svm and sdev according to a pasid and device. Add a helper to achieve
> this for code consolidation and readability.
>
> Signed-off-by: Lu Baolu
> ---
>
> From: Lu Baolu
> Sent: Monday, July 6, 2020 8:26 AM
>
> A pasid might be bound to a page table from a VM guest via the iommu
> ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
> on the physical IOMMU, we need to inject the page fault request into
> the guest. After the
> From: Lu Baolu
> Sent: Wednesday, July 15, 2020 9:00 AM
>
> Hi Christoph and Jacob,
>
> On 7/15/20 12:29 AM, Jacob Pan wrote:
> > On Tue, 14 Jul 2020 09:25:14 +0100
> > Christoph Hellwig wrote:
> >
> >> On Tue, Jul 14, 2020 at 01:57:03PM +0800, Lu Baolu wrote:
> >>> Replace
> From: Liu, Yi L
> Sent: Thursday, July 9, 2020 8:32 AM
>
> Hi Alex,
>
> > Alex Williamson
> > Sent: Thursday, July 9, 2020 3:55 AM
> >
> > On Wed, 8 Jul 2020 08:16:16 +
> > "Liu, Yi L" wrote:
> >
> > > Hi Alex,
> > >
> > > > From: Liu, Yi L < yi.l@intel.com>
> > > > Sent: Friday,
> From: Liu, Yi L
> Sent: Thursday, July 9, 2020 10:08 AM
>
> Hi Kevin,
>
> > From: Tian, Kevin
> > Sent: Thursday, July 9, 2020 9:57 AM
> >
> > > From: Liu, Yi L
> > > Sent: Thursday, July 9, 2020 8:32 AM
> > >
> > > H
> From: Lu Baolu
> Sent: Thursday, July 9, 2020 3:06 PM
>
> A pasid might be bound to a page table from a VM guest via the iommu
> ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
> on the physical IOMMU, we need to inject the page fault request into
> the guest. After the
> From: Lu Baolu
> Sent: Friday, July 10, 2020 1:37 PM
>
> Hi Kevin,
>
> On 2020/7/10 10:42, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Thursday, July 9, 2020 3:06 PM
> >>
> >> After page requests are handled, software must re
> From: Lu Baolu
> Sent: Thursday, July 9, 2020 3:06 PM
>
> After page requests are handled, software must respond to the device
> which raised the page request with the result. This is done through
> the iommu ops.page_response if the request was reported to outside of
> vendor iommu driver
> From: Liu, Yi L
> Sent: Wednesday, June 17, 2020 2:20 PM
>
> > From: Jacob Pan
> > Sent: Tuesday, June 16, 2020 11:22 PM
> >
> > On Thu, 11 Jun 2020 17:27:27 -0700
> > Jacob Pan wrote:
> >
> > > >
> > > > But then I thought it even better if VFIO leaves the entire
> > > > copy_from_user() to
> From: Liu, Yi L
> Sent: Monday, June 15, 2020 2:05 PM
>
> Hi Kevin,
>
> > From: Tian, Kevin
> > Sent: Monday, June 15, 2020 9:23 AM
> >
> > > From: Liu, Yi L
> > > Sent: Friday, June 12, 2020 5:05 PM
> > >
> > > Hi Ale
> From: Stefan Hajnoczi
> Sent: Monday, June 15, 2020 6:02 PM
>
> On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > 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
> From: Jacob Pan
> Sent: Friday, June 12, 2020 8:27 AM
>
> On Thu, 11 Jun 2020 14:40:47 -0600
> Alex Williamson wrote:
>
> > On Thu, 11 Jun 2020 12:52:05 -0700
> > Jacob Pan wrote:
> >
> > > Hi Alex,
> > >
> > > On Thu, 11 Jun 2020 09:47:41 -0600
> > > Alex Williamson wrote:
> > >
> > > >
> From: Liu, Yi L
> Sent: Friday, June 12, 2020 5:05 PM
>
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, June 12, 2020 3:30 AM
> >
> > On Thu, 11 Jun 2020 05:15:21 -0700
> > Liu Yi L wrote:
> >
> > > IOMMUs that support nesting translation needs report the capability
> > > info to
> From: Alex Williamson
> Sent: Wednesday, July 29, 2020 3:20 AM
>
[...]
> > +
> > +For example, IOTLB invalidations should always succeed. There is no
> > +architectural way to report back to the vIOMMU if the UAPI data is
> > +incompatible. If that happens, in order to guarantee IOMMU
> From: Alex Williamson
> Sent: Friday, July 31, 2020 4:17 AM
>
> On Wed, 29 Jul 2020 23:49:20 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, July 30, 2020 4:25 AM
> > >
> > > On Tue, 14 Jul 202
> From: Tian, Kevin
> Sent: Friday, July 31, 2020 8:26 AM
>
> > From: Alex Williamson
> > Sent: Friday, July 31, 2020 4:17 AM
> >
> > On Wed, 29 Jul 2020 23:49:20 +
> > "Tian, Kevin" wrote:
> >
> > > > F
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> The aux-domain apis were designed for macro driver where the subdevices
> are created and used inside a device driver. Use the device's bus iommu
> ops instead of that in iommu domain for various callbacks.
IIRC there are only two
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> The iommu_ops will only take effect when INTEL_IOMMU_SCALABLE_IOV
> kernel
> option is selected. It applies to any device passthrough framework which
> implements an underlying bus for the subdevices.
>
> - Subdevice probe:
> When
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> With the IOMMU driver registering iommu_ops for the mdev_bus, the
> IOMMU
> operations on an mdev could be done in the same way as any normal device
> (for example, PCI/PCIe). There's no need to distinguish an mdev from
> others for
> From: Lu Baolu
> Sent: Saturday, January 16, 2021 11:54 AM
>
> Hi Jean,
>
> On 2021/1/15 0:41, Jean-Philippe Brucker wrote:
> > I guess detailing what's needed for nested IOPF can help the discussion,
> > although I haven't seen any concrete plan about implementing it, and it
> > still seems
> From: Lu Baolu
> Sent: Thursday, January 21, 2021 9:45 AM
>
> So that the uses could get chances to know what happened.
>
> Suggested-by: Ashok Raj
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/svm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git
> From: Lu Baolu
> Sent: Thursday, January 14, 2021 9:30 AM
>
> The pci_subdevice_msi_create_irq_domain() should fail if the underlying
> platform is not able to support IMS (Interrupt Message Storage). Otherwise,
> the isolation of interrupt is not guaranteed.
>
> For x86, IMS is only supported
> From: Lu Baolu
> Sent: Monday, January 25, 2021 2:29 PM
>
> Hi Kevin,
>
> On 2021/1/22 14:38, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Thursday, January 21, 2021 9:45 AM
> >>
> >> So that the uses could get chances to
> From: Lu Baolu
> Sent: Wednesday, January 13, 2021 10:50 AM
>
> Hi Jean,
>
> On 1/12/21 5:16 PM, Jean-Philippe Brucker wrote:
> > Hi Baolu,
> >
> > On Tue, Jan 12, 2021 at 12:31:23PM +0800, Lu Baolu wrote:
> >> Hi Jean,
> >>
> >> On 1/8/21 10:52 PM, Jean-Philippe Brucker wrote:
> >>> Some
> From: Jason Gunthorpe
> Sent: Tuesday, February 2, 2021 7:44 AM
>
> On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > > we would get both sharing address and stable I/O
> From: Lu Baolu
> Sent: Wednesday, February 3, 2021 5:33 PM
>
> From: Yian Chen
>
> Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
> table structure. SATC table lists a set of SoC integrated devices that
> require ATC to work (VT-d specification v3.2, section 8.8).
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, January 26, 2021 9:27 AM
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> > Sent: Tuesday, January 26, 2021 2:13 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: Wangzhou (B) ; Greg Kroah-Hartman
> > ; Arnd
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:59 AM
>
> On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 16, 2021 7:41 AM
> > >
> > > On Tue, Jun 15, 2021 at 11:09:37
> From: Alex Williamson
> Sent: Wednesday, June 16, 2021 12:12 AM
>
> On Tue, 15 Jun 2021 02:31:39 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, June 15, 2021 12:28 AM
> > >
> > [...]
> > &g
> From: Alex Williamson
> Sent: Wednesday, June 16, 2021 12:56 AM
>
> On Tue, 15 Jun 2021 01:21:35 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, June 14, 2021 9:38 PM
> > >
> >
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:02 AM
>
> On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, June 15, 2021 11:07 PM
> > >
> > > On Tue, Jun 15, 2021 at 08:59:
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:41 AM
>
> On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
>
> > which information can you elaborate? This is the area which I'm not
> > familiar with thus would appreciate if you can help explai
> From: Jason Gunthorpe
> Sent: Tuesday, June 15, 2021 11:07 PM
>
> On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > Hi, Jason,
> >
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > >
> From: Jason Gunthorpe
> Sent: Monday, June 14, 2021 9:38 PM
>
> On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
>
> > If a device can be always blocked from accessing memory in the IOMMU
> > before it's bound to a driver or more specifically
> From: Alex Williamson
> Sent: Monday, June 14, 2021 11:23 AM
>
[...]
> > In the meantime, I'm thinking about another way whether group
> > security can be enforced in the iommu layer to relax the uAPI design.
> > If a device can be always blocked from accessing memory in the
> > IOMMU before
> From: Alex Williamson
> Sent: Tuesday, June 15, 2021 12:28 AM
>
[...]
> > IOASID. Today the group fd requires an IOASID before it hands out a
> > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it
> > has a blocked DMA IOASID and is successefully joined to an iommu_fd.
>
>
> From: David Gibson
> Sent: Tuesday, June 8, 2021 8:50 AM
>
> On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way the SW mode is the
> From: Alex Williamson
> Sent: Wednesday, June 9, 2021 2:47 AM
>
> On Tue, 8 Jun 2021 15:44:26 +0200
> Paolo Bonzini wrote:
>
> > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > >
> > Alternatively you can add a
> From: Eric Auger
> Sent: Wednesday, June 9, 2021 4:15 PM
>
> Hi Kevin,
>
> On 6/7/21 4:58 AM, Tian, Kevin wrote:
> > Hi, all,
> >
> > We plan to work on v2 now, given many good comments already received
> > and substantial changes envisioned. This
> From: Leon Romanovsky
> Sent: Wednesday, June 9, 2021 5:02 PM
>
> On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > Hi, all,
>
> <...>
>
> > (Remaining opens in v1)
>
> <...>
>
> > - Device-centric (Ja
Hi, Alex,
> From: Alex Williamson
> Sent: Thursday, June 10, 2021 11:39 PM
>
> On Wed, 9 Jun 2021 15:49:40 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
> >
> > > > > It is a kernel decision, because a fundamental task of the kernel is
> From: Alex Williamson
> Sent: Saturday, June 12, 2021 5:39 AM
>
> On Fri, 11 Jun 2021 00:58:35 +0000
> "Tian, Kevin" wrote:
>
> > Hi, Alex,
> >
> > > From: Alex Williamson
> > > Sent: Thursday, June 10, 2021 11:39 PM
> > >
&
201 - 300 of 775 matches
Mail list logo
