> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 1:26 PM
>
> Extend qi_submit_sync() function to support multiple descriptors.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/dmar.c| 39 +++--
> include/linux/intel-iommu.h
> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 4:30 PM
>
> On 2020/4/15 16:18, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Wednesday, April 15, 2020 1:26 PM
> >>
> >> Extend qi_submit_sync() function to support multiple descriptors.
>
> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 1:26 PM
>
> Move the software processing page request descriptors part from
> prq_event_thread() into a separated function. No any functional
> changes.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-svm.c | 256 --
> From: Lu Baolu
> Sent: Wednesday, April 15, 2020 1:26 PM
>
> Currently, the page request interrupt thread handles the page
> requests in the queue in this way:
>
> - Clear PPR bit to ensure new interrupt could come in;
> - Read and record the head and tail registers;
> - Handle all descriptors
> 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 remapping
> hardware. This adds the interface to drain page requests and
> call it when a PASID is terminated.
>
> Signe
> From: Jacob Pan
> Sent: Wednesday, April 15, 2020 11:39 PM
>
> On Tue, 14 Apr 2020 23:47:40 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Wednesday, April 15, 2020 6:32 AM
> > >
> > > On Tue, 14 Apr 2020 10
> From: Liu, Yi L
> Sent: Thursday, April 16, 2020 6:40 PM
>
> Hi Alex,
> Still have a direction question with you. Better get agreement with you
> before heading forward.
>
> > From: Alex Williamson
> > Sent: Friday, April 3, 2020 11:35 PM
> [...]
> > > > > + *
> > > > > + * returns: 0 on succ
> From: Auger Eric
> Sent: Thursday, April 16, 2020 8:43 PM
>
> Hi Kevin,
> On 4/16/20 2:09 PM, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Thursday, April 16, 2020 6:40 PM
> >>
> >> Hi Alex,
> >> Still have a direction question
> From: Lu Baolu
> Sent: Thursday, April 16, 2020 4:38 PM
>
> Hi Kevin,
>
> On 2020/4/15 19:10, Tian, Kevin wrote:
> > the completion of above sequence ensures that previous queued
> > page group responses are sent out and received by the endpoint
> > and
> From: Auger Eric
> Sent: Thursday, April 16, 2020 6:43 PM
>
[...]
> >>> + if (svm) {
> >>> + /*
> >>> + * If we found svm for the PASID, there must be at
> >>> + * least one device bond, otherwise svm should be
> >>> freed.
> >>> + */
> >>> + if (WARN_O
> From: Jacob Pan
> Sent: Friday, April 17, 2020 11:29 PM
>
> On Fri, 17 Apr 2020 09:46:55 +0200
> Auger Eric wrote:
>
> > Hi Kevin,
> > On 4/17/20 4:45 AM, Tian, Kevin wrote:
> > >> From: Auger Eric
> > >> Sent: Thursday, April 16, 2
> 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: 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: 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.
Abo
> 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 des
> 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
> Base:
> 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 pr
> 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.
>
> Signed-off
> 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 ch
> 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 cha
> 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 poss
er nesting 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...
> 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 gu
> 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.
> >
> >
> 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 outside
> 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: 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:
> > >
> > > > On
> 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 us
> 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: 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: Raj, Ashok
> Sent: Tuesday, September 24, 2019 4:26 AM
>
> Hi Jacob
>
> On Mon, Sep 23, 2019 at 12:27:15PM -0700, Jacob Pan wrote:
> > >
> > > In VT-d 3.0, scalable mode is introduced, which offers two level
> > > translation page tables and nested translation mode. Regards to
> > > GIOVA
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 12:31 PM
>
> On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote:
> > > > intel_mmmap_range(domain, addr, end, phys_addr, prot)
> > >
> > > Maybe think of a different name..? mmmap seems a bit weird :-)
> >
> >
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, September 23, 2019 8:25 PM
>
> If a dmar domain has DOMAIN_FLAG_FIRST_LEVEL_TRANS bit set
> in its flags, IOMMU will use the first level page table for
> translation. Hence, we need to map or unmap addresses in the
> first level pa
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 2:57 PM
>
> On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote:
> > Hi Kevin,
> >
> > On 9/24
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Wednesday, September 25, 2019 2:52 PM
>
> Hi Peter and Kevin,
>
> On 9/25/19 1:24 PM, Peter Xu wrote:
> > On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
> >>> From: Peter Xu [mailto:pet.
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 2:50 PM
>
> On Mon, Sep 23, 2019 at 08:24:54PM +0800, Lu Baolu wrote:
> > +/*
> > + * Check and return whether first level is used by default for
> > + * DMA translation.
> > + */
> > +static bool first_level_by_defa
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 3:45 PM
>
> On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > > From: Peter Xu [mailto:pet...@redhat.com]
> > > Sent: Wednesday, September 25, 2019 2:57 PM
> > &
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 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
> ---
> drivers/iommu/dm
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 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 PASI
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 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
> X
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 12:43 PM
>
> Hi Baolu,
>
> Thanks for the review. please see my comments inline.
>
> On Fri, 25 Oct 2019 10:30:48 +0800
> Lu Baolu wrote:
>
> > Hi Jacob,
> >
> > On 10/25/19 3:54 AM, Jacob Pan wrote:
> >
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
>
> Signed-off-by: Jacob Pan
better push this patch separately. It's a generic clean
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> After each setup for PASID entry, related translation caches must be
> flushed.
> We can combine duplicated code into one function which is less error
> prone.
>
> Signed-off-by: Jacob Pan
simi
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> 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 [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 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
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
from outside of host IOMMU subsystem
> This patch add
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 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
> From: Liu Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
> platforms allow address space sharing between device DMA and
> applications.
> SVA can reduce programming complexity and enhance security.
> This series is in
> From: Liu, Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> From: Liu Yi L
>
> When the guest "owns" the stage 1 translation structures, the host
> IOMMU driver has no knowledge of caching structure updates unless
> the guest invalidation requests are trapped and passed down to the
> host.
> From: Liu Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims
> to passdown PASID allocation/free request from the virtual
> iommu. This is required to get PASID managed in system-wide.
>
> Cc: Kevin Tian
> Signed-off-by: Liu Yi L
> Si
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, October 25, 2019 10:39 PM
>
> Hi,
>
> On 10/25/19 2:40 PM, Tian, Kevin wrote:
> >>>> ioasid_register_allocator(&iommu->pasid_allocator);
> >>>> +if
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Saturday, October 26, 2019 1:34 AM
>
> Hi Kevin,
>
>
> On Fri, 25 Oct 2019 07:19:26 +
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Saturday, October 26, 2019 3:03 PM
>
> Hi again,
>
> On 10/26/19 10:40 AM, Lu Baolu wrote:
> > Hi,
> >
> > On 10/25/19 3:27 PM, Tian, Kevin wrote:
> >>> From: Jacob Pan [mailto:jacob.jun.
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Tuesday, October 29, 2019 12:03 AM
>
> On Mon, 28 Oct 2019 06:03:36 +0000
> "Tian, Kevin" wrote:
>
> > > > > + .sva_bind_gpasid= intel_svm_bind_gpasid,
> > > > &g
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Wednesday, October 30, 2019 12:12 AM
>
> On Tue, 29 Oct 2019 07:57:21 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > > Sent: Tuesday
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Wednesday, October 30, 2019 1:15 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 (SV
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Tuesday, October 29, 2019 12:11 AM
>
> On Mon, 28 Oct 2019 06:06:33 +0000
> "Tian, Kevin" wrote:
>
> > > >>> + /* PASID based dev TLBs, only support all PASIDs or sin
> From: Yongji Xie
> Sent: Wednesday, April 27, 2016 8:43 PM
>
> This patch enables mmapping MSI-X tables if hardware supports
> interrupt remapping which can ensure that a given pci device
> can only shoot the MSIs assigned for it.
>
> With MSI-X table mmapped, we also need to expose the
> read/
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> Sent: Tuesday, May 03, 2016 2:08 PM
>
> On 2016/5/3 13:34, Tian, Kevin wrote:
>
> >> From: Yongji Xie
> >> Sent: Wednesday, April 27, 2016 8:43 PM
> >>
> >> This patch enables mmappi
> From: Yongji Xie
> Sent: Tuesday, May 03, 2016 3:34 PM
>
> On 2016/5/3 14:22, Tian, Kevin wrote:
>
> >> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> >> Sent: Tuesday, May 03, 2016 2:08 PM
> >>
> >> On 2016/5/3 13:34, Tian, Ke
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> Sent: Thursday, May 05, 2016 7:43 PM
>
> Hi David and Kevin,
>
> On 2016/5/5 17:54, David Laight wrote:
>
> > From: Tian, Kevin
> >> Sent: 05 May 2016 10:37
> > ...
> >>> Acu
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 05, 2016 11:05 PM
>
> On Thu, 5 May 2016 12:15:46 +0000
> "Tian, Kevin" wrote:
>
> > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> > > Sent: Thursday, May 0
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, May 11, 2016 11:54 PM
>
> On Wed, 11 May 2016 06:29:06 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursda
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 12, 2016 10:21 AM
>
> On Thu, 12 May 2016 01:19:44 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:48 AM
>
> On Thu, 12 May 2016 04:53:19 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, Ma
> From: Tian, Kevin
> Sent: Friday, May 13, 2016 10:33 AM
>
> > means. The MSI-X vector table of a device is always considered
> > untrusted which is why we require user opt-ins to subvert that
> > protection. Thanks,
> >
>
> I only partially agree with
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:33 PM
> > >
> > > As argued previously in this thread, there's nothing special about a
> > > DMA write to memory versus a DMA write to a special address that
> > > triggers an MSI vector. If the device is DM
> From: Jean-Philippe Brucker
> Sent: Tuesday, August 1, 2017 4:26 PM
>
> It depends what type you use when registering the IOMMU with
> VFIO_SET_IOMMU:
>
> * If the type is VFIO_TYPE1v2_IOMMU, then
> VFIO_IOMMU_MAP/UNMAP_DMA
> affects the stage-1 non-PASID context (already the case in mainline
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Friday, August 4, 2017 5:43 PM
>
> Hi Kevin,
>
> On 04/08/17 02:49, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Tuesday, August 1, 2017 4:26 PM
> >>
>
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, August 7, 2017 8:52 PM
>
> Hi Bob,
>
> On 07/08/17 13:18, Bob Liu wrote:
> > On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
> >> On 05/08/17 06:14, valmiki wrote:
> >> [...]
> >>> Hi Jean, Thanks a lot, now i un
> From: valmiki [mailto:valmiki...@gmail.com]
> Sent: Saturday, August 12, 2017 8:11 PM
>
> On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
> > On 05/08/17 06:14, valmiki wrote:
> > [...]
> >> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> >> documentation we fill vaddr and
> From: Raj, Ashok
> Sent: Saturday, August 12, 2017 12:25 AM
>
> On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote:
> > Hi Kevin,
> >
> >
> > Consider the situation where a userspace driver (no virtualization) is
> > built in a client-server fashion: the server controls a devi
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, August 5, 2017 2:19 AM
>
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now rese
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, April 24, 2017 11:06 PM
> 1. Attach device
>
>
> struct virtio_iommu_req_attach {
> le32address_space;
> le32device;
> le32flags/reserved;
> >>
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, August 21, 2017 8:00 PM
>
> On 21/08/17 08:59, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> >> Sent: Monday, April 24, 2017 11:06
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, August 22, 2017 10:19 PM
>
> On 22/08/17 07:24, Tian, Kevin wrote:
> >>> (sorry to pick up this old thread, as the .tex one is not good for review
> >>> and this thread prov
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, August 23, 2017 6:01 PM
>
> On 04/08/17 19:19, Jean-Philippe Brucker wrote:
> > Other extensions are in preparation. I won't detail them here because
> v0.4
> > already is a lot to digest, but in short, buildin
> From: Bharat Kumar Gogada [mailto:bhara...@xilinx.com]
> Sent: Monday, August 28, 2017 9:10 PM
>
> > Subject: RE: Support SVM without PASID
> >
> > > From: valmiki [mailto:valmiki...@gmail.com]
> > > Sent: Saturday, August 12, 2017 8:11 PM
> > >
> > > On 8/7/2017 4:01 PM, Jean-Philippe Brucker w
> From: Jean-Philippe Brucker
> Sent: Wednesday, September 6, 2017 7:55 PM
>
> Hi Kevin,
>
> On 28/08/17 08:39, Tian, Kevin wrote:
> > Here comes some comments:
> >
> > 1.1 Motivation
> >
> > You describe I/O page faults handling as future work. S
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, September 6, 2017 7:49 PM
>
>
> > 2.6.8.2.1
> > Multiple overlapping RESV_MEM properties are merged together. Device
> > requirement? if same types I assume?
>
> Combination rules apply to device and driver.
> From: Raj, Ashok
> Sent: Friday, September 29, 2017 1:11 AM
>
> Hi Jean
>
> On Thu, Sep 28, 2017 at 12:21:34PM +0100, Jean-Philippe Brucker wrote:
> > On 27/09/17 14:40, Joerg Roedel wrote:
> > > Hi,
> > >
> > > On Wed, Sep 20, 2017 at 01:09:47PM +0100, Jean-Philippe Brucker
> wrote:
> > >> For
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 2:33 AM
>
> Shared Virtual Addressing (SVA) provides a way for device drivers to bind
> process address spaces to devices. This requires the IOMMU to support the
> same page table format as CPUs, and requires the system to support I/
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 2:33 AM
>
> Add bind() and unbind() operations to the IOMMU API. Device drivers can
> use them to share process page tables with their devices. bind_group()
> is provided for VFIO's convenience, as it needs to provide a coherent
> in
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 2:33 AM
>
> When an mm exits, devices that were bound to it must stop performing
> DMA
> on its PASID. Let device drivers register a callback to be notified on mm
> exit. Add the callback to the iommu_param structure attached to stru
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 8:57 PM
>
> On 13/02/18 07:54, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Tuesday, February 13, 2018 2:33 AM
> >>
> >> Add bind() and unbind() operations to the
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 8:40 PM
>
>
> [...]
> >> +
> >> +/**
> >> + * iommu_sva_device_init() - Initialize Shared Virtual Addressing for a
> >> device
> >> + * @dev: the device
> >> + * @features: bitmask of features that need to be initialized
> >> + * @m
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, February 15, 2018 8:42 PM
>
> On 13/02/18 23:43, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Tues
> From: David Woodhouse
> Sent: Tuesday, February 27, 2018 3:48 PM
>
> On Mon, 2018-02-26 at 15:01 -0800, Alexander Duyck wrote:
> > I am interested in adding a new memory mapping option that
> > establishes
> > one identity-mapped region for all DMA_TO_DEVICE mappings and
> creates
> > a new dyna
> From: Shameer Kolothum
> Sent: Friday, March 16, 2018 12:35 AM
>
> This retrieves the reserved regions associated with dev group and
> checks for conflicts with any existing dma mappings. Also update
> the iova list excluding the reserved regions.
>
> Signed-off-by: Shameer Kolothum
>
> ---
>
> From: Shameer Kolothum
> Sent: Friday, March 16, 2018 12:35 AM
>
> This series introduces an iova list associated with a vfio
> iommu. The list is kept updated taking care of iommu apertures,
> and reserved regions. Also this series adds checks for any conflict
> with existing dma mappings whene
> From: Shameerali Kolothum Thodi
> [mailto:shameerali.kolothum.th...@huawei.com]
>
> Hi Kevin,
>
> Thanks for taking a look at this series.
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Monday, March 19, 2
> From: Shameerali Kolothum Thodi
> [mailto:shameerali.kolothum.th...@huawei.com]
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Monday, March 19, 2018 7:52 AM
> > To: Shameerali Kolothum Thodi
> ;
>
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, March 21, 2018 6:55 AM
>
> On Mon, 19 Mar 2018 08:28:32 +0000
> "Tian, Kevin" wrote:
>
> > > From: Shameer Kolothum
> > > Sent: Friday, March 16, 2018 12:35 AM
&
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, March 21, 2018 6:38 AM
>
> On Mon, 19 Mar 2018 07:51:58 +0000
> "Tian, Kevin" wrote:
>
> > > From: Shameer Kolothum
> > > Sent: Friday, March 16, 2018 12:35 AM
&
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, February 14, 2018 10:54 PM
>
> The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
> requests such as map/unmap over virtio-mmio transport without
> emulating
> page tables. This implementatio
> From: Alex Williamson
> Sent: Thursday, March 22, 2018 1:11 AM
>
> On Wed, 21 Mar 2018 03:28:16 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, March 21, 2018 6:55 AM
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Wednesday, March 21, 2018 10:24 PM
>
> On 21/03/18 13:14, Jean-Philippe Brucker wrote:
> > On 21/03/18 06:43, Tian, Kevin wrote:
> > [...]
> >>> +
> >>> +#include
> >>>
> From: Tian, Kevin
> Sent: Thursday, March 22, 2018 6:06 PM
>
> > From: Robin Murphy [mailto:robin.mur...@arm.com]
> > Sent: Wednesday, March 21, 2018 10:24 PM
> >
> > On 21/03/18 13:14, Jean-Philippe Brucker wrote:
> >
> From: Jean-Philippe Brucker
> Sent: Wednesday, May 15, 2019 7:04 PM
>
> On 14/05/2019 18:44, Jacob Pan wrote:
> > Hi Thank you both for the explanation.
> >
> > On Tue, 14 May 2019 11:41:24 +0100
> > Jean-Philippe Brucker wrote:
> >
> >> On 14/05/2019 08:36, Auger Eric wrote:
> >>> Hi Jacob,
>
101 - 200 of 784 matches
Mail list logo
