RE: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

From: Daniel Vetter Sent: Monday, July 07, 2014 11:40 AM On Mon, Jul 07, 2014 at 07:58:30PM +0200, Paolo Bonzini wrote: Il 07/07/2014 19:54, Daniel Vetter ha scritto: On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote: Il 07/07/2014 16:49, Daniel Vetter ha scritto: So the

RE: [Xen-devel] [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Friday, July 11, 2014 12:42 PM On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote: On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote: actually I'm curious whether it's still necessary to __detect__ PCH

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

Here is some background of this KVMGT release: - the major purpose is for early experiment of this technique in KVM, and throw out issues about adding in-kernel device model (or mediated pass-through framework) in KVM. - KVMGT shares 90% code as XenGT, regarding to vGPU device model. The only

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

From: Daniel Vetter Sent: Monday, December 08, 2014 6:21 PM On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote: On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote: I don't know that is exactly needed, we also need to have Windows driver considered. However, I'm quite

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

From: Song, Jike Sent: Wednesday, December 10, 2014 2:34 PM CC Kevin. On 12/09/2014 05:54 PM, Jan Kiszka wrote: On 2014-12-04 03:24, Jike Song wrote: Hi all, We are pleased to announce the first release of KVMGT project. KVMGT is the implementation of Intel GVT-g technology,

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: Thursday, December 11, 2014 12:59 AM On 09/12/2014 03:49, Tian, Kevin wrote: - Now we have XenGT/KVMGT separately maintained, and KVMGT lags behind XenGT regarding to features and qualities. Likely you'll continue see stale code

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Tian, Kevin > Sent: Friday, November 20, 2015 4:36 PM > > > > > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it > > > > can feed it into the vnc server. The vfio framebuffer region is meant > > > > to s

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, November 19, 2015 2:12 AM > > [cc +qemu-devel, +paolo, +gerd] > > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > > Hi all, > > > > We are pleased to announce another update of Intel GVT-g for Xen. > > > > Intel

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Friday, November 20, 2015 4:26 PM > > Hi, > > > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't > > > explain how the guest framebuffer can be accessed then. > > > > You can check "fb_decoder.h". One thing to

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Tian, Kevin > Sent: Friday, November 20, 2015 3:10 PM > > > > > > > > The proposal is therefore that GPU vendors can expose vGPUs to > > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio > > > > supports modul

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Song, Jike > Sent: Friday, November 20, 2015 1:52 PM > > On 11/20/2015 12:22 PM, Alex Williamson wrote: > > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote: > >> On 11/19/2015 11:52 PM, Alex Williamson wrote: > >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: > On

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Thursday, November 19, 2015 4:41 PM > > Hi, > > > > Another area of extension is how to expose a framebuffer to QEMU for > > > seamless integration into a SPICE/VNC channel. For this I believe we > > > could use a new region, much like

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, November 20, 2015 4:03 AM > > > > > > > The proposal is therefore that GPU vendors can expose vGPUs to > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio > > > supports modular bus drivers and

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 v3 00/11] KVM: x86: track guest page access

> From: Song, Jike > Sent: Tuesday, February 23, 2016 11:02 AM > > +Kevin > > On 02/22/2016 06:05 PM, Xiao Guangrong wrote: > > > > On 02/19/2016 08:00 PM, Paolo Bonzini wrote: > >> > >> I still have a doubt: how are you going to handle invalidation of GPU > >> shadow page tables if a device

RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination

> From: Wu, Feng > Sent: Thursday, January 21, 2016 12:43 PM > > > -Original Message- > > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On > > Behalf Of Yang Zhang > > Sent: Thursday, January 21, 2016 11:35 AM > > To: Wu, Feng ; pbonz...@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" <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" <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: 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: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: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: 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] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:22 PM > > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough a PCI device with

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

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

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

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

> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > Sent: Tuesday, May 03, 2016 1:52 PM > > >> + > >> + if (!(res->start & ~PAGE_MASK)) { > >> + /* > >> + * Add shadow resource for sub-page bar whose mmio > >> + * page is exclusive

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: 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 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 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 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 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: 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 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 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: [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: [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 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 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 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 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 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 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: [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: [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: 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 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: 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 [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 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: 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 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 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] 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: 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 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: 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: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

> From: Daniel Vetter > Sent: Monday, July 07, 2014 11:40 AM > > On Mon, Jul 07, 2014 at 07:58:30PM +0200, Paolo Bonzini wrote: > > Il 07/07/2014 19:54, Daniel Vetter ha scritto: > > >On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote: > > >>Il 07/07/2014 16:49, Daniel Vetter ha

RE: [Xen-devel] [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Friday, July 11, 2014 12:42 PM > > On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote: > > On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote: > > > actually I'm curious w

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: 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 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 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 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: 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 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 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 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: [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: [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 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 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: 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 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] 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: [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] 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 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 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 1/3] iommu/vt-d: Add rate limited information when PRQ overflows

> 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

RE: [PATCH 1/3] iommu/vt-d: Add rate limited information when PRQ overflows

> 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

RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain

> From: Leon Romanovsky > Sent: Thursday, January 7, 2021 12:02 AM > > On Wed, Jan 06, 2021 at 11:23:39AM -0400, Jason Gunthorpe wrote: > > On Wed, Jan 06, 2021 at 12:40:17PM +0200, Leon Romanovsky wrote: > > > > > I asked what will you do when QEMU will gain needed functionality? > > > Will you

RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain

> From: Leon Romanovsky > Sent: Thursday, January 7, 2021 2:09 PM > > On Thu, Jan 07, 2021 at 02:04:29AM +, Tian, Kevin wrote: > > > From: Leon Romanovsky > > > Sent: Thursday, January 7, 2021 12:02 AM > > > > > > On Wed, Jan 06,

RE: [RFC PATCH 1/1] platform-msi: Add platform check for subdevice irq domain

> From: David Woodhouse > Sent: Thursday, December 10, 2020 4:23 PM > > On Thu, 2020-12-10 at 08:46 +0800, Lu Baolu wrote: > > +/* > > + * We want to figure out which context we are running in. But the > hardware > > + * does not introduce a reliable way (instruction, CPUID leaf, MSR, >

RE: [RFC PATCH v3 2/2] platform-msi: Add platform check for subdevice irq domain

> 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

RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

> From: Jason Gunthorpe > Sent: Friday, August 7, 2020 8:20 PM > > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > > > If you see this as an abuse of the framework, then let's identify those > > specific issues and come up with a better approach. As we've discussed > >

RE: [PATCH v2 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

> 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

RE: [PATCH v3 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

> 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

RE: [PATCH 1/1] iommu/vt-d: Use device numa domain if RHSA is missing

> 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

RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

> From: Alex Williamson > Sent: Wednesday, August 12, 2020 1:01 AM > > On Mon, 10 Aug 2020 07:32:24 +0000 > "Tian, Kevin" wrote: > > > > From: Jason Gunthorpe > > > Sent: Friday, August 7, 2020 8:20 PM > > > > > >

RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

> From: Alex Williamson > Sent: Wednesday, August 12, 2020 10:36 AM > On Wed, 12 Aug 2020 01:58:00 +0000 > "Tian, Kevin" wrote: > > > > > > > I'll also remind folks that LPC is coming up in just a couple short > > > weeks and this might be som

RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

> From: Jason Wang > Sent: Wednesday, August 12, 2020 11:28 AM > > > On 2020/8/10 下午3:32, Tian, Kevin wrote: > >> From: Jason Gunthorpe > >> Sent: Friday, August 7, 2020 8:20 PM > >> > >> On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Willi

RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

> From: Jason Wang > Sent: Thursday, August 13, 2020 12:34 PM > > > On 2020/8/12 下午12:05, Tian, Kevin wrote: > >> The problem is that if we tie all controls via VFIO uAPI, the other > >> subsystem like vDPA is likely to duplicate them. I wonder if there is a

RE: [PATCH v3] PCI: Introduce flag for detached virtual functions

> From: kvm-ow...@vger.kernel.org On Behalf > Of Niklas Schnelle > Sent: Friday, August 28, 2020 5:10 PM > To: Bjorn Helgaas ; Alex Williamson > > [...] > >> > >> FWIW, pci_physfn() never returns NULL, it returns the provided pdev if > >> is_virtfn is not set. This proposal wouldn't change

RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

> From: Thomas Gleixner > Sent: Friday, November 13, 2020 6:43 AM > > On Thu, Nov 12 2020 at 14:32, Konrad Rzeszutek Wilk wrote: > >> 4. Using CPUID to detect running as guest. But as Thomas pointed out, this > >> approach is less reliable as not all hypervisors do this way. > > > > Is that

RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

> From: Raj, Ashok > Sent: Monday, November 16, 2020 8:23 AM > > On Sun, Nov 15, 2020 at 11:11:27PM +0100, Thomas Gleixner wrote: > > On Sun, Nov 15 2020 at 11:31, Ashok Raj wrote: > > > On Sun, Nov 15, 2020 at 12:26:22PM +0100, Thomas Gleixner wrote: > > >> > opt-in by device or kernel? The way

RE: [PATCH v6 2/5] iommu: Use bus iommu ops for aux related callback

> 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

RE: [PATCH v6 4/5] iommu/vt-d: Add iommu_ops support for subdevice bus

> 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

RE: [PATCH v6 5/5] vfio/type1: Use mdev bus iommu_ops for IOMMU callbacks

> 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

RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

> From: Jason Gunthorpe > Sent: Tuesday, November 10, 2020 10:24 PM > > On Tue, Nov 10, 2020 at 06:13:23AM -0800, Raj, Ashok wrote: > > > This isn't just for idxd, as I mentioned earlier, there are vendors other > > than Intel already working on this. In all cases the need for guest direct > >

  1   2   3   >