Re: [RFC PATCH v2 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote: > Current vfio-pci implementation disallows to mmap MSI-X > table in case that user get to touch this directly. > > However, EEH mechanism can ensure that a given pci device > can only shoot the MSIs assigned for its PE. So we think > it's safe

Re: [RFC PATCH v2 1/3] PCI: Add support for enforcing all MMIO BARs to be page aligned

On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote: > When vfio passthrough a PCI device of which MMIO BARs > are smaller than PAGE_SIZE, guest will not handle the > mmio accesses to the BARs which leads to mmio emulations > in host. > > This is because vfio will not allow to passthrough one >

Re: [PATCH] vfio/iommu_type1: make use of info.flags

On Wed, 2015-12-23 at 13:08 +0100, Pierre Morel wrote: > The flags entry is there to tell the user that some > optional information is available. > > Since we report the iova_pgsizes signal it to the user > by setting the flags to VFIO_IOMMU_INFO_PGSIZES. > > Signed-off-by: Pierre Morel

Re: [RFC 0/2] VFIO SRIOV support

On Thu, 2015-12-24 at 07:22 +, Ilya Lesokhin wrote: > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, December 23, 2015 6:28 PM > > To: Ilya Lesokhin <il...@mellanox.com>; kvm@vger.kernel.org; l

Re: [RFC 0/2] VFIO SRIOV support

On Wed, 2015-12-23 at 07:43 +, Ilya Lesokhin wrote: > Hi Alex, > Regarding driver_override, as far as I know you can only use it on > devices that were already discovered. Since the devices do not exist > before the call to pci_enable_sriov(...) > and are already probed after the call  it

Re: [RFC 0/2] VFIO SRIOV support

On Tue, 2015-12-22 at 15:42 +0200, Ilya Lesokhin wrote: > Today the QEMU hypervisor allows assigning a physical device to a VM, > facilitating driver development. However, it does not support > enabling > SR-IOV by the VM kernel driver. Our goal is to implement such > support, > allowing

Re: [patch] VFIO: platform: reset: fix a warning message condition

On Thu, 2015-12-17 at 15:27 +0300, Dan Carpenter wrote: > This loop ends with count set to -1 and not zero so the warning > message > isn't printed when it should be.  I've fixed this by change the > postop > to a preop. > > Fixes: 0990822c9866 ('VFIO: platform: reset: AMD xgbe reset module') >

Re: [PATCH kernel] vfio: Add explicit alignments in vfio_iommu_spapr_tce_create

On Fri, 2015-12-18 at 12:35 +1100, Alexey Kardashevskiy wrote: > The vfio_iommu_spapr_tce_create struct has 4x32bit and 2x64bit fields > which should have resulted in sizeof(fio_iommu_spapr_tce_create) > equal > to 32 bytes. However due to the gcc's default alignment, the actual > size of this

[PATCH v3] vfio: Include No-IOMMU mode

mu support for the vfio-pci bus driver only. Signed-off-by: Alex Williamson <alex.william...@redhat.com> Acked-by: Michael S. Tsirkin <m...@redhat.com> --- v3: Version 2 was dropped from kernel v4.4 due to lack of a user. We now have a working DPDK port to this interface, so I'm proposing

[PATCH v4] vfio: Include No-IOMMU mode

mu support for the vfio-pci bus driver only. Signed-off-by: Alex Williamson <alex.william...@redhat.com> Acked-by: Michael S. Tsirkin <m...@redhat.com> --- v4: Fix build without CONFIG_VFIO_NOIOMMU (oops). Also avoid local noiommu variable in vfio_create_group() to avoid scope con

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 18:37 +0800, yongji xie wrote: > > On 2015/12/17 4:14, Alex Williamson wrote: > > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > > > Current vfio-pci implementation disallows to mmap MSI-X table in > > > case that user get to touch this

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 10:08 +, David Laight wrote: > > The MSI-X table is paravirtualized on vfio in general and interrupt > > remapping theoretically protects against errant interrupts, so why > > is > > this PPC64 specific? We have the same safeguards on x86 if we want > > to > > decide

Re: [RFC PATCH 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

On Thu, 2015-12-17 at 18:26 +0800, yongji xie wrote: > > On 2015/12/17 4:04, Alex Williamson wrote: > > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > > > Current vfio-pci implementation disallows to mmap > > > sub-page(size < PAGE_SIZE) MMIO BARs be

Re: [RFC PATCH 0/3] VFIO: capability chains

On Fri, 2015-12-18 at 13:05 +1100, Alexey Kardashevskiy wrote: > On 11/24/2015 07:43 AM, Alex Williamson wrote: > > Please see the commit log and comments in patch 1 for a general > > explanation of the problems that this series tries to address.  The > > general problem is

Re: [PATCH 2/5] VIRT: Support runtime irq_bypass consumer

On Thu, 2015-12-03 at 10:22 -0800, Yunhong Jiang wrote: > Extend the irq_bypass manager to support runtime consumers. A runtime > irq_bypass consumer can handle interrupt when an interrupt triggered. A > runtime consumer has it's handle_irq() function set and passing a > irq_context for the irq

Re: [PATCH 3/5] VFIO: Support threaded interrupt handling on VFIO

On Thu, 2015-12-03 at 10:22 -0800, Yunhong Jiang wrote: > For VFIO device with MSI interrupt type, it's possible to handle the > interrupt on hard interrupt context without invoking the interrupt > thread. Handling the interrupt on hard interrupt context reduce the > interrupt latency. > >

Re: [RFC PATCH 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > 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. > > But we should allow to mmap these sub-page MMIO BARs if all MMIO BARs > are page

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > Current vfio-pci implementation disallows to mmap MSI-X table in > case that user get to touch this directly. > > However, EEH mechanism could ensure that a given pci device > can only shoot the MSIs assigned for its PE and guest kernel also

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Wed, 2015-12-16 at 18:56 +0100, Paolo Bonzini wrote: > Alex, > > can you take a look at the extension to the irq bypass interface in > patch 2?  I'm not sure I understand what is the case where you have > multiple consumers for the same token. The consumers would be, for instance, Intel PI +

[GIT PULL] VFIO fixes for v4.4-rc5

Kozlowski, Julia Lawall, Kees Cook, Dan Carpenter) - Revert No-IOMMU mode as the intended user has not emerged (Alex Williamson) ---- Alex Williamson (1): Revert: "vfio: Include No-IOMMU mode" Dan Carpenter

Re: [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO

On Thu, 2015-12-03 at 16:16 +0300, Pavel Fedin wrote: > Hello! > > > I like that you're making this transparent > > for the user, but at the same time, directly calling function pointers > > through the msi_domain_ops is quite ugly. > > Do you mean dereferencing info->ops->vfio_map() in .c

Re: [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition

On Thu, 2015-12-03 at 16:40 +0800, Lan, Tianyu wrote: > On 12/3/2015 6:25 AM, Alex Williamson wrote: > > I didn't seen a matching kernel patch series for this, but why is the > > kernel more capable of doing this than userspace is already? > The following link is the ke

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

On Thu, 2015-12-03 at 10:22 -0800, Yunhong Jiang wrote: > When assigning a VFIO device to a KVM guest with low latency requirement, it > is better to handle the interrupt in the hard interrupt context, to reduce > the context switch to/from the IRQ thread. > > Based on discussion on

Re: [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition

On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote: > Signed-off-by: Lan Tianyu > --- > linux-headers/linux/vfio.h | 16 > 1 file changed, 16 insertions(+) > > diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h > index 0508d0b..732b0bd

Re: [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO

On Tue, 2015-11-24 at 16:50 +0300, Pavel Fedin wrote: > On some architectures (e.g. ARM64) if the device is behind an IOMMU, and > is being mapped by VFIO, it is necessary to also add mappings for MSI > translation register for interrupts to work. This series implements the > necessary API to do

Re: [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote: > This patch is to add SRIOV VF migration support. > Create new device type "vfio-sriov" and add faked PCI migration capability > to the type device. > > The purpose of the new capability > 1) sync migration status with VF driver in the VM > 2)

Re: [RFC PATCH V2 06/10] Qemu/PCI: Add macros for faked PCI migration capability

On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote: > This patch is to extend PCI CAP id for migration cap and > add reg macros. The CAP ID is trial and we may find better one if the > solution is feasible. > > *PCI_VF_MIGRATION_CAP > For VF driver to control that triggers mailbox irq or not

Re: [PATCH 5/7] vfio: fix a problematic usage of WARN()

On Wed, 2015-11-25 at 21:12 +0800, Geliang Tang wrote: > WARN() takes a condition and a format string. The condition was > omitted. So I added it. > > Signed-off-by: Geliang Tang > --- > drivers/vfio/vfio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

[RFC PATCH 3/3] vfio/pci: Include sparse mmap capability for MSI-X table regions

-areas within the region that can be mmap'd, we can make the mmap constraints more explicit. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- drivers/vfio/pci/vfio_pci.c | 101 +++ 1 file changed, 100 insertions(+), 1 deletion(-) diff

[RFC PATCH 0/3] VFIO: capability chains

of these capabilities is entirely dynamic. Comments welcome, I'll also follow-up to the QEMU and KVM lists with an RFC making use of this for mmaps skipping over the MSI-X table. Thanks, Alex --- Alex Williamson (3): vfio: Define capability chains vfio: Define sparse mmap capability

[RFC PATCH 2/3] vfio: Define sparse mmap capability for regions

with fixed region index to BAR number mapping. We therefore define a new capability which lists areas within the region that may be mmap'd. In addition to the MSI-X case, this potentially enables in-kernel emulation and extensions to devices. Signed-off-by: Alex Williamson <alex.william...@redhat.

[RFC PATCH 1/3] vfio: Define capability chains

-off-by: Alex Williamson <alex.william...@redhat.com> --- include/uapi/linux/vfio.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 751b69f..432569f 100644 --- a/include/uapi/linux/vfio.h +++ b/i

[RFC post-2.5 PATCH 2/5] vfio: Generalize region support

ed because otherwise we don't know how the caller has allocated VFIORegion and therefore don't know whether to unreference it to destroy the MemoryRegion or not. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- hw/vfio/common.c | 169 ++

[RFC post-2.5 PATCH 1/5] vfio: Wrap VFIO_DEVICE_GET_REGION_INFO

In preparation for supporting capability chains on regions, wrap ioctl(VFIO_DEVICE_GET_REGION_INFO) so we don't duplicate the code for each caller. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- hw/vfio/common.c | 18 + hw/vfio/pci.c

[RFC post-2.5 PATCH 4/5] linux-headers/vfio: Update for proposed capabilities list

Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- linux-headers/linux/vfio.h | 53 +++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h index aa276bc..c3860f6

[RFC post-2.5 PATCH 3/5] vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions

Match common vfio code with setup, exit, and finalize functions for BAR, quirk, and VGA management. VGA is also changed to dynamic allocation to match the other MemoryRegions. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- hw/vfio/pci-quirks.c | 38 - h

[RFC post-2.5 PATCH 0/5] VFIO: capability chains

and of course kernel header updates would only be included when accepted upstream. Thanks, Alex --- Alex Williamson (5): vfio: Wrap VFIO_DEVICE_GET_REGION_INFO vfio: Generalize region support vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions linux

[RFC post-2.5 PATCH 5/5] vfio: Enable sparse mmap capability

. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- hw/vfio/common.c | 66 +++--- trace-events |2 ++ 2 files changed, 64 insertions(+), 4 deletions(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index a73c6ad..3b7cf23

Re: [PATCH 9/9] vfio-pci: constify pci_error_handlers structures

On Sat, 2015-11-14 at 11:07 +0100, Julia Lawall wrote: > This pci_error_handlers structure is never modified, like all the other > pci_error_handlers structures, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > There

Re: [RESEND PATCH] vfio: Drop owner assignment from platform_driver

On Thu, 2015-11-19 at 13:00 +0900, Krzysztof Kozlowski wrote: > platform_driver does not need to set an owner because > platform_driver_register() will set it. > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Baptiste Reynal > > ---

[GIT PULL] VFIO updates for v4.4-rc1

to 222e684ca762e9288108fcf852eb5d08cbe10ae3: vfio/pci: make an array larger (2015-11-09 08:59:11 -0700) VFIO updates for v4.4-rc1 - Use kernel interfaces for VPD emulation (Alex Williamson) - Platform fix for releasing IRQs (Eric Auger) - Type1 IOMMU always

Re: [patch v2] vfio/pci: make an array larger

On Mon, 2015-11-09 at 15:24 +0300, Dan Carpenter wrote: > Smatch complains about a possible out of bounds error: > > drivers/vfio/pci/vfio_pci_config.c:1241 vfio_cap_init() > error: buffer overflow 'pci_cap_length' 20 <= 20 > > The problem is that pci_cap_length[] was defined as

Re: [PATCH] vfio: Fix bug in vfio_device_get_from_name()

On Wed, 2015-11-04 at 13:53 +0100, Joerg Roedel wrote: > From: Joerg Roedel > > The vfio_device_get_from_name() function might return a > non-NULL pointer, when called with a device name that is not > found in the list. This causes undefined behavior, in my > case calling an

Re: [patch] vfio: make an array larger

On Wed, 2015-11-04 at 16:26 +0300, Dan Carpenter wrote: > Smatch complains about a possible out of bounds error: > > drivers/vfio/pci/vfio_pci_config.c:1241 vfio_cap_init() > error: buffer overflow 'pci_cap_length' 20 <= 20 > > Fix this by making the array larger. > > Signed-off-by:

Re: [patch] vfio: make an array larger

On Wed, 2015-11-04 at 21:20 +0300, Dan Carpenter wrote: > Sorry, I should have said that I am on linux-next at the start. > > > > -static u8 pci_cap_length[] = { > > > +static u8 pci_cap_length[PCI_CAP_ID_MAX + 1] = { > > > [PCI_CAP_ID_BASIC] = PCI_STD_HEADER_SIZEOF, /* pci config header

[PATCH v2] vfio: Include No-IOMMU mode

mu support for the vfio-pci bus driver only. Signed-off-by: Alex Williamson <alex.william...@redhat.com> Acked-by: Michael S. Tsirkin <m...@redhat.com> --- v2: A minor change to the vfio_for_each_iommu_driver macro: @@ -229,7 +229,7 @@ static struct vfio_iommu_driver vfio_noiommu_driver = {

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, 2015-10-28 at 01:44 +0100, Paolo Bonzini wrote: > > On 27/10/2015 22:26, Yunhong Jiang wrote: > >> > On RT kernels however can you call eventfd_signal from interrupt > >> > context? You cannot call spin_lock_irqsave (which can sleep) from a > >> > non-threaded interrupt handler, can you?

Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size

On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote: > Current vfio_pgsize_bitmap code hides the supported IOMMU page > sizes smaller than PAGE_SIZE. As a result, in case the IOMMU > does not support PAGE_SIZE page, the alignment check on map/unmap > is done with larger page sizes, if any. This

Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size

On Wed, 2015-10-28 at 18:10 +0100, Eric Auger wrote: > Hi Alex, > On 10/28/2015 05:27 PM, Alex Williamson wrote: > > On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote: > >> Current vfio_pgsize_bitmap code hides the supported IOMMU page > >> sizes smaller than P

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, 2015-10-28 at 10:50 -0700, Yunhong Jiang wrote: > On Wed, Oct 28, 2015 at 01:44:55AM +0100, Paolo Bonzini wrote: > > > > > > On 27/10/2015 22:26, Yunhong Jiang wrote: > > >> > On RT kernels however can you call eventfd_signal from interrupt > > >> > context? You cannot call

Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size

On Wed, 2015-10-28 at 17:14 +, Will Deacon wrote: > On Wed, Oct 28, 2015 at 10:27:28AM -0600, Alex Williamson wrote: > > On Wed, 2015-10-28 at 13:12 +, Eric Auger wrote: > > > diff --git a/drivers/vfio/vfio_iommu_type1.c > > > b/drivers/vfio/vfio_iommu_type1.c &

Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size

On Wed, 2015-10-28 at 19:00 +0100, Eric Auger wrote: > On 10/28/2015 06:55 PM, Will Deacon wrote: > > On Wed, Oct 28, 2015 at 06:48:41PM +0100, Eric Auger wrote: > >> On 10/28/2015 06:37 PM, Alex Williamson wrote: > >>> Ok, so with hopefully correcting my under

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Wed, 2015-10-28 at 18:05 +0100, Paolo Bonzini wrote: > > On 28/10/2015 17:00, Alex Williamson wrote: > > > Alex, would it make sense to use the IRQ bypass infrastructure always, > > > not just for VT-d, to do the MSI injection directly from the VFIO > >

Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

[cc +iommu] On Tue, 2015-10-27 at 15:40 +, Will Deacon wrote: > On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote: > > On Fri, 2015-10-16 at 16:03 +0200, Eric Auger wrote: > > > Hi Alex, > > > On 10/15/2015 10:52 PM, Alex Williamson wrote: > >

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ, > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when > assigning a device to a guest with low latency requirement since it > reduce the context switch to/from the

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Fri, 2015-10-23 at 11:36 -0700, Alexander Duyck wrote: > On 10/21/2015 09:37 AM, Lan Tianyu wrote: > > This patchset is to propose a new solution to add live migration support > > for 82599 > > SRIOV network card. > > > > Im our solution, we prefer to put all device specific operation into VF

Re: [Qemu-devel] [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Thu, 2015-10-22 at 15:32 +0300, Michael S. Tsirkin wrote: > On Wed, Oct 21, 2015 at 01:20:27PM -0600, Alex Williamson wrote: > > The trouble here is that the VF needs to be unplugged prior to the start > > of migration because we can't do effective dirty page tracking while

Re: [PATCH v2 6/6] vfio: platform: move get/put reset at open/release

On Thu, 2015-10-22 at 16:23 +0200, Eric Auger wrote: > On 10/22/2015 04:10 PM, Arnd Bergmann wrote: > > On Thursday 22 October 2015 15:26:55 Eric Auger wrote: > @@ -181,6 +182,8 @@ static int vfio_platform_open(void *device_data) > if (ret) >

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Thu, 2015-10-22 at 18:58 +0300, Or Gerlitz wrote: > On Wed, Oct 21, 2015 at 10:20 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > > This is why the typical VF agnostic approach here is to using bonding > > and fail over to a emulated device durin

Re: [RFC PATCH 0/3] Qemu/IXGBE: Add live migration support for SRIOV NIC

On Thu, 2015-10-22 at 00:52 +0800, Lan Tianyu wrote: > This patchset is Qemu part for live migration support for SRIOV NIC. > kernel part patch information is in the following link. > http://marc.info/?l=kvm=144544635330193=2 > > > Lan Tianyu (3): > Qemu: Add pci-assign.h to share functions

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On Wed, 2015-10-21 at 21:45 +0300, Or Gerlitz wrote: > On Wed, Oct 21, 2015 at 7:37 PM, Lan Tianyu wrote: > > This patchset is to propose a new solution to add live migration support > > for 82599 SRIOV network card. > > > In our solution, we prefer to put all device

Re: [PATCH 1/4] vfio: platform: add capability to register a reset function

On Sun, 2015-10-18 at 18:00 +0200, Eric Auger wrote: > In preparation for subsequent changes in reset function lookup, > lets introduce a dynamic list of reset combos (compat string, > reset module, reset function). The list can be populated/voided with > two new functions,

[PATCH v3 1/2] qapi: Create DEFINE_PROP_STRING_LEN

A slight addition to set_string(), which optionally tests that the string length is within the bounds specified. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- hw/core/qdev-properties.c|7 +++ include/hw/qdev-core.h |1 + include/hw/qdev-properties.h

[PATCH v3 2/2] kvm: Allow the Hyper-V vendor ID to be specified

-vendor-id option to the -cpu flag to allow for this, ex: -cpu host,hv_time,hv_vendor_id=KeenlyKVM Link: http://msdn.microsoft.com/library/windows/hardware/hh975392 Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- target-i386/cpu-qom.h |1 + target-i386/cpu.c

[PATCH v3 0/2] Enable specifying a non-default Hyper-V vendor ID

take value '123456789abcd' v2: Remove abort, but truncate string --- Alex Williamson (2): qapi: Create DEFINE_PROP_STRING_LEN kvm: Allow the Hyper-V vendor ID to be specified hw/core/qdev-properties.c|7 +++ include/hw/qdev-core.h |1 + include/hw/qdev

[PATCH v2] kvm: Allow the Hyper-V vendor ID to be specified

-vendor-id option to the -cpu flag to allow for this, ex: -cpu host,hv_time,hv_vendor_id=KeenlyKVM Link: http://msdn.microsoft.com/library/windows/hardware/hh975392 Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- v2: Replace abort() with truncating the string, error report u

Re: [RESEND PATCH] kvm: Allow the Hyper-V vendor ID to be specified

On Fri, 2015-10-16 at 09:30 +0200, Paolo Bonzini wrote: > > On 16/10/2015 00:16, Alex Williamson wrote: > > According to Microsoft documentation, the signature in the standard > > hypervisor CPUID leaf at 0x4000 identifies the Vendor ID and is > > for reporting and

Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

On Fri, 2015-10-16 at 16:03 +0200, Eric Auger wrote: > Hi Alex, > On 10/15/2015 10:52 PM, Alex Williamson wrote: > > We can only provide isolation if DMA is forced through the IOMMU > > aperture. Don't allow type1 to be used if this is not the case. > > > >

[RESEND PATCH] kvm: Allow the Hyper-V vendor ID to be specified

-vendor-id option to the -cpu flag to allow for this, ex: -cpu host,hv_time,hv_vendor_id=KeenlyKVM Link: http://msdn.microsoft.com/library/windows/hardware/hh975392 Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- Cc'ing get_maintainers this time. Any takers? Thanks

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thu, 2015-10-15 at 21:42 +0200, Christoffer Dall wrote: > On Thu, Oct 15, 2015 at 10:53:17AM -0600, Alex Williamson wrote: > > On Thu, 2015-10-15 at 16:46 +0200, Eric Auger wrote: > > > Hi Arnd, > > > On 10/15/2015 03:59 PM, Arnd Bergmann wrote: > > > &g

[RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

We can only provide isolation if DMA is forced through the IOMMU aperture. Don't allow type1 to be used if this is not the case. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- Eric, I see a number of IOMMU drivers enable this, do the ones you care about for A

[PATCH] vfio/pci: Use kernel VPD access functions

access through sysfs, but the window of opportunity is much smaller. Signed-off-by: Alex Williamson <alex.william...@redhat.com> Acked-by: Mark Rustad <mark.d.rus...@intel.com> --- I posted this about a month ago as an RFC and it got positive feedback as a thing we should do. Therefore,

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Thu, 2015-10-15 at 16:46 +0200, Eric Auger wrote: > Hi Arnd, > On 10/15/2015 03:59 PM, Arnd Bergmann wrote: > > On Thursday 15 October 2015 14:12:28 Christoffer Dall wrote: > >>> > >>> enum vfio_platform_op { > >>> VFIO_PLATFORM_BIND, > >>> VFIO_PLATFORM_UNBIND, > >>>

Re: BUG: unable to handle kernel paging request with v4.3-rc4

On Fri, 2015-10-09 at 16:58 +0200, Joerg Roedel wrote: > Hi Alex, > > while playing around with attaching a 32bit PCI device to a guest via > VFIO I triggered this oops: > > [ 192.289917] kernel tried to execute NX-protected page - exploit attempt? > (uid: 0) > [ 192.298245] BUG: unable to

Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt

On Tue, 2015-10-06 at 08:32 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, October 06, 2015 4:15 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 4/6] vfio: Add interface to iommu-map/unmap MSI pages

On Tue, 2015-10-06 at 09:05 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, October 06, 2015 4:15 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state

On Tue, 2015-10-06 at 08:53 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, October 06, 2015 4:15 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region

On Tue, 2015-10-06 at 09:39 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, October 06, 2015 4:15 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region

On Mon, 2015-10-05 at 04:55 +, Bhushan Bharat wrote: > Hi Alex, > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Saturday, October 03, 2015 4:16 AM > > To: Bhushan Bharat-R65777 <bharat.b

Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt

On Mon, 2015-10-05 at 07:20 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Saturday, October 03, 2015 4:17 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state

On Mon, 2015-10-05 at 06:00 +, Bhushan Bharat wrote: > > -1138,6 +1156,8 @@ > > > static long vfio_iommu_type1_ioctl(void *iommu_data, > > > } > > > } else if (cmd == VFIO_IOMMU_GET_INFO) { > > > struct vfio_iommu_type1_info info; > > > + struct

Re: [RFC PATCH 4/6] vfio: Add interface to iommu-map/unmap MSI pages

On Mon, 2015-10-05 at 06:27 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Saturday, October 03, 2015 4:16 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

Re: [RFC PATCH 6/6] arm-smmu: Allow to set iommu mapping for MSI

On Mon, 2015-10-05 at 08:33 +, Bhushan Bharat wrote: > > > > -Original Message- > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Saturday, October 03, 2015 4:17 AM > > To: Bhushan Bharat-R65777 <bharat.bhus...@freescale.com>

[PATCH] kvm: Allow the Hyper-V vendor ID to be specified

-vendor-id option to the -cpu flag to allow for this, ex: -cpu host,hv_time,hv_vendor_id=KeenlyKVM Link: http://msdn.microsoft.com/library/windows/hardware/hh975392 Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- target-i386/cpu-qom.h |1 + target-i386/cpu.c

Re: [RFC PATCH 5/6] vfio-pci: Create iommu mapping for msi interrupt

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > An MSI-address is allocated and programmed in pcie device > during interrupt configuration. Now for a pass-through device, > try to create the iommu mapping for this allocted/programmed > msi-address. If the iommu mapping is created and

Re: [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This Patch adds the VFIO APIs to add and remove reserved iova > regions. The reserved iova region can be used for mapping some > specific physical address in iommu. > > Currently we are planning to use this interface for adding iova >

Re: [RFC PATCH 6/6] arm-smmu: Allow to set iommu mapping for MSI

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > Finally ARM SMMU declare that iommu-mapping for MSI-pages are not > set automatically and it should be set explicitly. > > Signed-off-by: Bharat Bhushan > --- > drivers/iommu/arm-smmu.c | 7 ++- > 1

Re: [RFC PATCH 4/6] vfio: Add interface to iommu-map/unmap MSI pages

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > For MSI interrupts to work for a pass-through devices we need > to have mapping of msi-pages in iommu. Now on some platforms > (like x86) does this msi-pages mapping happens magically and in these > case they chooses an iova which they

Re: [RFC PATCH 2/6] iommu: Add interface to get msi-pages mapping attributes

[really ought to consider cc'ing the iommu list] On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This APIs return the capability of automatically mapping msi-pages > in iommu with some magic iova. Which is what currently most of > iommu's does and is the default behaviour. > > Further

Re: [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state

On Wed, 2015-09-30 at 20:26 +0530, Bharat Bhushan wrote: > This patch allows the user-space to know whether msi-pages > are automatically mapped with some magic iova or not. > > Even if the msi-pages are automatically mapped, still user-space > wants to over-ride the automatic iova selection for

Re: PCI passthrough problem

On Thu, 2015-10-01 at 22:38 -0400, Phil (list) wrote: > On Thu, 2015-10-01 at 08:32 -0400, Mauricio Tavares wrote: > > On Thu, Oct 1, 2015 at 3:27 AM, Phil (list) > > wrote: > > > If this isn't the right place to ask, any pointers to the correct > > > place > > > are

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, 2015-09-21 at 22:11 +1000, Gavin Shan wrote: > On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: > >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: > >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: > >> > On

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, 2015-09-21 at 22:11 +1000, Gavin Shan wrote: > On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: > >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: > >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: > >> > On

Re: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

and review patch 12? I sent an ack for 12 separately, I got a bit lost in 16 & 17, but for all the others that don't already have some tag from me, Reviewed-by: Alex Williamson <alex.william...@redhat.com> > > Joerg, can you ack patch 18? > > Paolo > > >

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote: > This allows to accept IOMMU group (PE) ID from the parameter from userland > when handling EEH operation so that the operation only affects the target > IOMMU group (PE). If the IOMMU group (PE) ID in the parameter from userland > is invalid,

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote: > This allows to accept IOMMU group (PE) ID from the parameter from userland > when handling EEH operation so that the operation only affects the target > IOMMU group (PE). If the IOMMU group (PE) ID in the parameter from userland > is invalid,

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

ration" in the dev_info, otherwise: Acked-by: Alex Williamson <alex.william...@redhat.com> > --- > v8: > - Merge "[PATCH v7 08/17] vfio: Select IRQ_BYPASS_MANAGER for vfio PCI > devices" > into this patch. > > v6: > - Make the add_consumer and del_co

Re: [Qemu-devel] [PATCH 1/2] target-i386: disable LINT0 after reset

On Mon, 2015-04-13 at 02:32 +0300, Nadav Amit wrote: > Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone > and therefore this hack is no longer needed. Since it violates the > specifications, it is removed. > > Signed-off-by: Nadav Amit >

Re: [RFC PATCH] vfio/pci: Use kernel VPD access functions

On Sat, 2015-09-12 at 01:11 +, Rustad, Mark D wrote: > Alex, > > > On Sep 11, 2015, at 11:16 AM, Alex Williamson <alex.william...@redhat.com> > > wrote: > > > > RFC - Is this something we should do? > > Superficially this looks pret

[RFC PATCH] vfio/pci: Use kernel VPD access functions

access through sysfs, but the window of opportunity is much smaller. Signed-off-by: Alex Williamson <alex.william...@redhat.com> --- RFC - Is this something we should do? Should we consider providing similar emulation through PCI sysfs to allow lspci to also make use of the vpd inte

  1   2   3   4   5   6   7   8   9   10   >