RE: [PATCH v2 02/15] iommu: Report domain nesting info

> 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

RE: [PATCH v2 1/3] docs: IOMMU user API

> 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: > > > > > > >

RE: (a design open) RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host

> 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. > > > >

RE: (a design open) RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host

> 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

(a design open) RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host

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

RE: [PATCH RFC 00/15] Add VFIO mediated device support and IMS support for the idxd driver.

> From: Jason Gunthorpe > Sent: Saturday, May 9, 2020 8:21 PM > > > putting emulation code back into them, except in a more dangerous > > > kernel location. This does not seem like a net win to me. > > > > Its not a whole lot of emulation right? mdev are soft partitioned. There is > > just a

RE: [PATCH v4 3/5] iommu/vt-d: Disable non-recoverable fault processing before unbind

> 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

RE: [PATCH v4 0/5] iommu/vt-d: Add page request draining support

> 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

RE: [PATCH v4 5/5] iommu/vt-d: Remove redundant IOTLB flush

> 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

RE: [PATCH v4 4/5] iommu/vt-d: Add page request draining support

> 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. > >

RE: [PATCH v4 3/5] iommu/vt-d: Disable non-recoverable fault processing before unbind

> 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

RE: [PATCH v4 2/5] iommu/vt-d: debugfs: Add support to show inv queue internals

> 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 >

RE: [PATCH v4 1/5] iommu/vt-d: Multiple descriptors per qi_submit_sync()

> 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

RE: [PATCH RFC 04/15] drivers/base: Add support for a new IMS irq domain

> From: Jason Gunthorpe > Sent: Monday, May 4, 2020 8:14 PM > > On Sun, May 03, 2020 at 05:25:28PM -0700, Dey, Megha wrote: > > > > The use case if when we have a device assigned to a guest and we > > > > want to allocate IMS(platform-msi) interrupts for that > > > > guest-assigned device.

RE: [PATCH RFC 00/15] Add VFIO mediated device support and IMS support for the idxd driver.

> From: Jason Gunthorpe > Sent: Monday, April 27, 2020 9:22 PM > > On Mon, Apr 27, 2020 at 07:19:39AM -0600, Alex Williamson wrote: > > > > It is not trivial masking. It is a 2000 line patch doing comprehensive > > > emulation. > > > > Not sure what you're referring to, I see about 30 lines of

RE: [RFC PATCH 3/4] iommu/vt-d: Map/unmap domain with mmmap/mmunmap

> 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

RE: [PATCH v5 0/6] Deliver vGPU display refresh event to userspace

> From: Zhang, Tina > Sent: Tuesday, September 3, 2019 9:27 AM > > Hi, > > Some people are asking whether the display refresh irq could be provided by > qemu vfio display? > > Some background: currently, we have two display timers. One is provided by > QEMU UI and the other one is provided by

RE: [PATCH v5 4/6] drm/i915/gvt: Deliver vGPU refresh event to userspace

> From: Zhang, Tina > Sent: Wednesday, August 28, 2019 2:59 PM > > > -Original Message- > > From: Tian, Kevin > > Sent: Wednesday, August 28, 2019 9:50 AM > > To: Zhenyu Wang ; Zhang, Tina > > > > Cc: k...@vger.kernel.org; linux-kernel@v

RE: [PATCH v5 4/6] drm/i915/gvt: Deliver vGPU refresh event to userspace

> From: Zhenyu Wang > Sent: Monday, August 26, 2019 3:56 PM > > On 2019.08.16 10:35:26 +0800, Tina Zhang wrote: > > Deliver the display refresh events to the user land. Userspace can use > > the irq mask/unmask mechanism to disable or enable the event delivery. > > > > As we know, delivering

RE: [RFC PATCH v2 1/3] vfio: Use capability chains to handle device specific irq

> From: kra...@redhat.com > Sent: Wednesday, June 5, 2019 6:10 PM > > Hi, > > > > Really need to split for different planes? I'd like a > > > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_EVENT > > > so user space can probe change for all. > > > User space can choose to user different handlers according to

RE: [PATCH 1/1] iommu: Bind process address spaces to devices

> 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

RE: [PATCH v2 2/2] iommu/vt-d: Enable PASID only if device expects PASID in PRG Response.

> 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 ;

RE: [PATCH v1 1/2] vfio:iommu: Use capabilities do report IOMMU informations

> From: Shameerali Kolothum Thodi > [mailto:shameerali.kolothum.th...@huawei.com] > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: 09 January 2019 15:37 > > To: Pierre Morel > > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; > >

RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Tian, Kevin > Sent: Wednesday, July 25, 2018 10:16 AM > [...] > > > > There is another way: as we're planning to add a generic pasid_alloc() > > function to the IOMMU API, the mdev module itself could allocate a > > default PASID for each mdev by ca

RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

> From: Tian, Kevin > Sent: Wednesday, July 25, 2018 10:16 AM > [...] > > > > There is another way: as we're planning to add a generic pasid_alloc() > > function to the IOMMU API, the mdev module itself could allocate a > > default PASID for each mdev by ca

RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesda

RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesda

RE: [PATCH v2 0/9] iommu/vt-d: Improve PASID id and table management

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Wednesday, May 16, 2018 4:01 PM > > Hi Joerg, > > Thank you for looking at my patches. > > On 05/15/2018 10:11 PM, Joerg Roedel wrote: > > On Fri, May 04, 2018 at 09:41:15AM +0800, Lu Baolu wrote: > >> PATCH 4~9 implement per domain

RE: [PATCH v2 0/9] iommu/vt-d: Improve PASID id and table management

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Wednesday, May 16, 2018 4:01 PM > > Hi Joerg, > > Thank you for looking at my patches. > > On 05/15/2018 10:11 PM, Joerg Roedel wrote: > > On Fri, May 04, 2018 at 09:41:15AM +0800, Lu Baolu wrote: > >> PATCH 4~9 implement per domain

RE: [PATCH v6 2/5] KVM: x86: Add IBPB support

> From: Paolo Bonzini > Sent: Thursday, May 3, 2018 5:20 PM > > On 03/05/2018 03:27, Wanpeng Li wrote: > > So for 1) guest->guest attacks 2) guest/ring3->host/ring3 attacks 3) > > guest/ring0->host/ring0 attacks, if IBPB is enough to protect these > > three scenarios and retpoline is not needed?

RE: [PATCH v6 2/5] KVM: x86: Add IBPB support

> From: Paolo Bonzini > Sent: Thursday, May 3, 2018 5:20 PM > > On 03/05/2018 03:27, Wanpeng Li wrote: > > So for 1) guest->guest attacks 2) guest/ring3->host/ring3 attacks 3) > > guest/ring0->host/ring0 attacks, if IBPB is enough to protect these > > three scenarios and retpoline is not needed?

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, April 28, 2018 2:08 AM > > [...] > >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should > >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it > >> different from

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, April 28, 2018 2:08 AM > > [...] > >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should > >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it > >> different from

RE: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend

> From: Liang, Cunming > Sent: Tuesday, April 10, 2018 10:24 PM > [...] > > > > As others said, we do not need to go overeboard. A couple of small > vendor- > > specific quirks in qemu isn't a big deal. > > It's quite challenge to identify it's small or not, there's no uniform metric. > > It's

RE: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend

> From: Liang, Cunming > Sent: Tuesday, April 10, 2018 10:24 PM > [...] > > > > As others said, we do not need to go overeboard. A couple of small > vendor- > > specific quirks in qemu isn't a big deal. > > It's quite challenge to identify it's small or not, there's no uniform metric. > > It's

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> From: Alex Williamson > Sent: Thursday, March 22, 2018 1:11 AM > > On Wed, 21 Mar 2018 03:28:16 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, March

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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" <kevin.t...@intel.com> wrote: > > > > From: Shameer Kolothum > > > Sent: Friday

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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 &

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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" <kevin.t...@intel.com> wrote: > > > > From: Shameer Kolothum > > > Sent: Friday, March

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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 &

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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 > &

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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 > ; >

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> 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

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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 >

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> 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 > > --- >

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, March 3, 2018 2:14 AM > > On Fri, 2 Mar 2018 06:54:17 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson > > > Sent: Friday, Ma

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, March 3, 2018 2:14 AM > > On Fri, 2 Mar 2018 06:54:17 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Friday, March 2, 2018 4:22 AM > >

RE: [PATCH 0/3] vfio/pci: ioeventfd support

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, March 3, 2018 2:03 AM > > On Fri, 2 Mar 2018 07:08:51 +0000 > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson > > > Sent: Thursday

RE: [PATCH 0/3] vfio/pci: ioeventfd support

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, March 3, 2018 2:03 AM > > On Fri, 2 Mar 2018 07:08:51 +0000 > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Thursday, March 1, 2018 4:15 AM > > >

RE: [PATCH 0/3] vfio/pci: ioeventfd support

> From: Alex Williamson > Sent: Thursday, March 1, 2018 4:15 AM > > A vfio ioeventfd will perform the pre-specified device write on > triggering of an eventfd. When coupled with KVM ioeventfds, this > feature allows a VM to trap a device page for virtualization, while > also registering targeted

RE: [PATCH 0/3] vfio/pci: ioeventfd support

> From: Alex Williamson > Sent: Thursday, March 1, 2018 4:15 AM > > A vfio ioeventfd will perform the pre-specified device write on > triggering of an eventfd. When coupled with KVM ioeventfds, this > feature allows a VM to trap a device page for virtualization, while > also registering targeted

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Tian, Kevin > Sent: Friday, March 2, 2018 2:54 PM > > > From: Alex Williamson > > Sent: Friday, March 2, 2018 4:22 AM > > > > > > I am pretty sure that you are describing is true of some, but not for > > > all. I think the Amazon soluti

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Tian, Kevin > Sent: Friday, March 2, 2018 2:54 PM > > > From: Alex Williamson > > Sent: Friday, March 2, 2018 4:22 AM > > > > > > I am pretty sure that you are describing is true of some, but not for > > > all. I think the Amazon soluti

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Alex Williamson > Sent: Friday, March 2, 2018 4:22 AM > > > > I am pretty sure that you are describing is true of some, but not for > > all. I think the Amazon solutions and the virtio solution are doing > > hard partitioning of the part. I will leave it to those guys to speak > > for

RE: [PATCH] pci-iov: Add support for unmanaged SR-IOV

> From: Alex Williamson > Sent: Friday, March 2, 2018 4:22 AM > > > > I am pretty sure that you are describing is true of some, but not for > > all. I think the Amazon solutions and the virtio solution are doing > > hard partitioning of the part. I will leave it to those guys to speak > > for

RE: [PATCH v5] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

> From: Alex Williamson > Sent: Friday, February 23, 2018 6:59 AM > > On Thu, 1 Feb 2018 01:27:38 -0500 > Suravee Suthikulpanit wrote: > > > VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which > requires > > IOTLB flushing for every unmapping. This

RE: [PATCH v5] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

> From: Alex Williamson > Sent: Friday, February 23, 2018 6:59 AM > > On Thu, 1 Feb 2018 01:27:38 -0500 > Suravee Suthikulpanit wrote: > > > VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which > requires > > IOTLB flushing for every unmapping. This results in large IOTLB flushing

RE: [RFC]Add new mdev interface for QoS

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, August 2, 2017 6:26 AM > > On Tue, 1 Aug 2017 13:54:27 +0800 > "Gao, Ping A" wrote: > > > On 2017/7/28 0:00, Gao, Ping A wrote: > > > On 2017/7/27 0:43, Alex Williamson wrote: > > >> [cc

RE: [RFC]Add new mdev interface for QoS

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, August 2, 2017 6:26 AM > > On Tue, 1 Aug 2017 13:54:27 +0800 > "Gao, Ping A" wrote: > > > On 2017/7/28 0:00, Gao, Ping A wrote: > > > On 2017/7/27 0:43, Alex Williamson wrote: > > >> [cc +libvir-list] > > >> > > >>

RE: [PATCH 3/9] iommu: Introduce iommu do invalidate API function

> 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:

RE: [PATCH 3/9] iommu: Introduce iommu do invalidate API function

> 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:

RE: [PATCH 2/9] iommu/vt-d: add bind_pasid_table function

> 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,

RE: [PATCH 2/9] iommu/vt-d: add bind_pasid_table function

> 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,

RE: [PATCH v14 00/22] Add Mediated device support

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, November 18, 2016 5:25 AM > > On Thu, 17 Nov 2016 02:16:12 +0530 > Kirti Wankhede wrote: > > > > Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 ++ > > Documentation/vfio-mediated-device.txt

RE: [PATCH v14 00/22] Add Mediated device support

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, November 18, 2016 5:25 AM > > On Thu, 17 Nov 2016 02:16:12 +0530 > Kirti Wankhede wrote: > > > > Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 ++ > > Documentation/vfio-mediated-device.txt| 399 +++

RE: [PATCH v11 01/22] vfio: Mediated device Core driver

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Saturday, November 05, 2016 5:11 AM > [...] > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id: I73a5084574270b14541c529461ea2f03c292d510 Jike has given his reviewed-by for

RE: [PATCH v11 01/22] vfio: Mediated device Core driver

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Saturday, November 05, 2016 5:11 AM > [...] > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id: I73a5084574270b14541c529461ea2f03c292d510 Jike has given his reviewed-by for some patches in v10. Please include his

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Tian, Kevin > Sent: Wednesday, October 26, 2016 3:54 PM > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, October 20, 2016 5:03 AM > > > @@ -83,6 +92,21 @@ struct vfio_group { > > > }; > > > > > >

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Tian, Kevin > Sent: Wednesday, October 26, 2016 3:54 PM > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, October 20, 2016 5:03 AM > > > @@ -83,6 +92,21 @@ struct vfio_group { > > > }; > > > > > >

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, October 20, 2016 5:03 AM > > @@ -83,6 +92,21 @@ struct vfio_group { > > }; > > > > /* > > + * Guest RAM pinning working set or DMA target > > + */ > > +struct vfio_pfn { > > + struct rb_node node; > > +

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, October 20, 2016 5:03 AM > > @@ -83,6 +92,21 @@ struct vfio_group { > > }; > > > > /* > > + * Guest RAM pinning working set or DMA target > > + */ > > +struct vfio_pfn { > > + struct rb_node node; > > +

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Monday, October 24, 2016 10:32 AM > > > >> -static long vfio_unpin_pages(unsigned long pfn, long npage, > > >> - int prot, bool do_accounting) > > >> +static long __vfio_unpin_pages_remote(struct

RE: [PATCH v9 04/12] vfio iommu: Add support for mediated devices

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Monday, October 24, 2016 10:32 AM > > > >> -static long vfio_unpin_pages(unsigned long pfn, long npage, > > >> - int prot, bool do_accounting) > > >> +static long __vfio_unpin_pages_remote(struct

RE: [PATCH v9 02/12] vfio: VFIO based driver for Mediated devices

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > vfio_mdev driver registers with mdev core driver. > MDEV core driver creates mediated device and calls probe routine of use same case - either 'mdev core' or 'MDEV core' > vfio_mdev driver for

RE: [PATCH v9 02/12] vfio: VFIO based driver for Mediated devices

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > vfio_mdev driver registers with mdev core driver. > MDEV core driver creates mediated device and calls probe routine of use same case - either 'mdev core' or 'MDEV core' > vfio_mdev driver for

RE: [PATCH v9 01/12] vfio: Mediated device Core driver

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > Design for Mediated Device Driver: > Main purpose of this driver is to provide a common interface for mediated > device management that can be used by different drivers of different > devices. > >

RE: [PATCH v9 01/12] vfio: Mediated device Core driver

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > Design for Mediated Device Driver: > Main purpose of this driver is to provide a common interface for mediated > device management that can be used by different drivers of different > devices. > >

RE: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, June 24, 2016 11:37 AM > > On Fri, 24 Jun 2016 10:52:58 +0800 > Yongji Xie wrote: > > On 2016/6/24 0:12, Alex Williamson wrote: > > > On Mon, 30 May 2016 21:06:37 +0800 > > > Yongji Xie

RE: [PATCH v4] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, June 24, 2016 11:37 AM > > On Fri, 24 Jun 2016 10:52:58 +0800 > Yongji Xie wrote: > > On 2016/6/24 0:12, Alex Williamson wrote: > > > On Mon, 30 May 2016 21:06:37 +0800 > > > Yongji Xie wrote: > > >> +static void

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] &

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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" <kevin.t...@intel.com> wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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" <kevin.t...@intel.com> wrote: > > > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> 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

<    1   2   3   >