> ---
>
> Alex, please update your vfio patch accordingly.
Sure, thanks for the heads up.
Acked-by: Alex Williamson
>
> hw/virtio-pci.c |4 ++--
> kvm-all.c | 18 --
> kvm-stub.c | 14 ++
> kvm.h |6 ++
&
ake them, but I think this compromise is race-free and still
manages to make allocation of IRQ source IDs mostly a non-issue
for device assignment limits. Thanks,
Alex
---
Alex Williamson (2):
kvm: On Ack, De-assert & Notify KVM_IRQFD extension
kvm: Use a reserved IRQ source ID fo
y for userspace to test
for this fix.
Signed-off-by: Alex Williamson
---
arch/x86/kvm/x86.c |3 +++
include/linux/kvm.h |1 +
include/linux/kvm_host.h |1 +
virt/kvm/eventfd.c |6 +++---
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x8
de-asserts the gsi and notifies
via another eventfd. It's then the responsibility of the user to
re-assert the interrupt is service is still required.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt | 13 ++
arch/x86/kvm/x86.c|1
include/linux/kv
On Tue, 2012-08-21 at 22:58 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 01:29:06PM -0600, Alex Williamson wrote:
> > KVM_IRQFD currently uses the reserved KVM_USERSPACE_IRQ_SOURCE_ID
> > which is also shared with userspace injection methods like
> > KVM_IRQ_LI
On Tue, 2012-08-21 at 23:37 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 01:29:14PM -0600, Alex Williamson wrote:
> > For VFIO based device assignment we'd like a mechanism to allow level
> > triggered interrutps to be directly injected into KVM. KVM_IRQFD
>
On Tue, 2012-08-21 at 23:41 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 02:06:19PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-21 at 22:58 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 21, 2012 at 01:29:06PM -0600, Alex Williamson wrote:
> > >
On Wed, 2012-08-22 at 03:31 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 01:28:57PM -0600, Alex Williamson wrote:
> > Here's the much anticipated re-write of support for level irqfds. As
> > Michael suggested, I've rolled the eoi/ack notification fd into
&g
On Wed, 2012-08-22 at 03:41 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 03:14:54PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-21 at 23:41 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 21, 2012 at 02:06:19PM -0600, Alex Williamson wrote:
> > >
On Wed, 2012-08-22 at 03:14 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 21, 2012 at 03:11:41PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-21 at 23:37 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 21, 2012 at 01:29:14PM -0600, Ale
On Tue, 2012-08-28 at 09:23 +, Bhushan Bharat-R65777 wrote:
> Hi Alex,
>
> In my susyem I have following devices:
>
> I tried assigning a following PCI devices:
> 00:03.0 Communication controller: Intel Corporation 4 Series Chipset HECI
> Controller (rev 03)
> 00:03.2 IDE interface: Intel Co
On Tue, 2012-08-28 at 17:10 +, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, August 28, 2012 9:27 PM
> > To: Bhushan Bharat-R65777
> > Cc: kvm@vger.kernel.org;
On Wed, 2012-08-29 at 07:11 +, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, August 29, 2012 12:16 PM
> > To: Bhushan Bharat-R65777
> > Cc: kvm@vger.kernel.org;
On Wed, 2012-08-29 at 18:42 +, Bhushan Bharat-R65777 wrote:
> PFA file which have full dmeg and lspci of assigned device
> On Aug 29, 2012 11:03 AM, "Bhushan Bharat-R65777"
> mailto:r65...@freescale.com>> wrote:
> > Guest>lspci
> > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [N
On Mon, 2012-09-03 at 18:59 +0300, Avi Kivity wrote:
> On 08/29/2012 11:49 AM, Peter Maydell wrote:
> > On 29 August 2012 09:47, Jan Kiszka wrote:
> >> On 2012-08-28 23:26, Peter Maydell wrote:
> >>> Since this is arch-specific we should probably give the
> >>> resulting device a more specific nam
On Tue, 2011-08-23 at 12:38 +1000, David Gibson wrote:
> On Mon, Aug 22, 2011 at 09:45:48AM -0600, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
> > > On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> > > > We ha
On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
>
> > I'm not following you.
> >
> > You have to enforce group/iommu domain assignment whether you have the
> > existing uiommu API, or if you change it to your proposed
> > ioctl
On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> On Mon, Aug 22, 2011 at 03:17:00PM -0400, Alex Williamson wrote:
> > On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
>
> > > I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> > > assig
On Tue, 2011-08-23 at 10:33 -0700, Aaron Fabbri wrote:
>
>
> On 8/23/11 10:01 AM, "Alex Williamson" wrote:
>
> > On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
> >>
> &g
On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-08-22 at 09:45 -0600, Alex Williamson wrote:
>
> > Yes, that's the idea. An open question I have towards the configuration
> > side is whether we might add iommu driver specific options
On Tue, 2011-08-23 at 15:31 +0200, Jan Kiszka wrote:
> Hi Alex,
>
> just ran into some corner case with my reanimated IRQ sharing patches
> that may affect vfio as well:
>
> How are vfio_enable/disable_intx synchronized against all other possible
> spots that call pci_block_user_cfg_access?
>
>
21 ---
> hw/device-assignment.c | 405
> ++--
> hw/device-assignment.h |9 +-
> hw/pci.c | 29 ++--
> hw/pci.h |7 +-
> hw/pci_regs.h |7 -
> 6 files changed, 174 insertions(+), 304 deletions(-)
>
For s
On Wed, 2011-08-24 at 09:51 +1000, Benjamin Herrenschmidt wrote:
> > > For us the most simple and logical approach (which is also what pHyp
> > > uses and what Linux handles well) is really to expose a given PCI host
> > > bridge per group to the guest. Believe it or not, it makes things
> > > easi
On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
> On Tue, Aug 23, 2011 at 03:30:06PM -0400, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
>
> > > Could be tho in what form ? returning sysfs pathes ?
> >
> > I&
On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
>
> > > Handling it through fds is a good idea. This makes sure that everything
> > >
On Wed, 2011-08-24 at 11:09 +0200, Jan Kiszka wrote:
> On 2011-08-24 00:05, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 15:31 +0200, Jan Kiszka wrote:
> >> Hi Alex,
> >>
> >> just ran into some corner case with my reanimated IRQ sharing patches
> >>
Joerg,
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would AMD-Vi do something similar (or
exactly the same) for group #s? Thanks,
Alex
Signed-off-by: Alex
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> Hi Alex,
>
> On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> > Is this roughly what you're thinking of for the iommu_group component?
> > Adding a dev_to_group iommu ops callback let&
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections that I missed.
VFIO v2 will rely on the platform iommu driver reporting grouping
information. Again, a group is a set of devices for
On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
>
> > > We need to solve this differently. ARM is starting to use the iommu-api
> > &g
On Mon, 2011-08-29 at 16:51 +, Yoder Stuart-B08248 wrote:
> Alex Graf, Scott Wood, and I met last week to try to flesh out
> some details as to how vfio could work for non-PCI devices,
> like we have in embedded systems. This most likely will
> require a different kernel driver than vfio-- fo
On Mon, 2011-08-29 at 16:58 -0500, Scott Wood wrote:
> On 08/29/2011 02:51 PM, Alex Williamson wrote:
> > On Mon, 2011-08-29 at 16:51 +, Yoder Stuart-B08248 wrote:
> >> The device info records following the file header have the following
> >> record types each with
On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
> On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
> >
> > I don't think too much has changed since the previous email went out,
> > but it seems like a good idea to post a summary in case the
On Mon, 2011-08-29 at 18:14 -0500, Scott Wood wrote:
> On 08/29/2011 05:46 PM, Alex Williamson wrote:
> > On Mon, 2011-08-29 at 16:58 -0500, Scott Wood wrote:
> >> On 08/29/2011 02:51 PM, Alex Williamson wrote:
> >>> On Mon, 2011-08-29 at 16:51 +, Yoder Stuart-B
On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
> > > On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
> > > >
>
illing the test program
with devices/iommus open. The locking is overly simplistic.
But, it's a start. Please make constructive comments and
suggestions. Patches based on v3.0. Thanks,
Alex
---
Alex Williamson (5):
VFIO: Simple test tool
VFIO: Add PCI device support
VFIO
dependencies between devices
for managing safe, user space drivers.
Signed-off-by: Alex Williamson
---
drivers/base/iommu.c | 51 +
include/linux/iommu.h |6 ++
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/base
o add an option to group multi-function (non-SR-IOV) devices
together. It's disturbingly not uncommon for functions to have
dependencies between each other on the same device and systems
may wish to enforce that they are grouped together.
Signed-off-by: Alex Williamson
---
drivers/pci/
Signed-off-by: Alex Williamson
---
drivers/Kconfig |2
drivers/Makefile|1
drivers/vfio/Kconfig|5
drivers/vfio/Makefile |3
drivers/vfio/vfio_device.c | 109 +
drivers/vfio/vfio_iommu.c | 81
drivers/vfio/vfio_main.c
Signed-off-by: Alex Williamson
---
drivers/vfio/Kconfig|7 ++
drivers/vfio/Makefile |1
drivers/vfio/vfio_main.c| 10 +++
drivers/vfio/vfio_pci.c | 124 +++
drivers/vfio/vfio_private.h |5 ++
5 files changed, 147
Signed-off-by: Alex Williamson
---
tools/testing/vfio/Makefile|4
tools/testing/vfio/vfio_test.c | 406
2 files changed, 410 insertions(+), 0 deletions(-)
create mode 100644 tools/testing/vfio/Makefile
create mode 100644 tools/testing/vfio
On Thu, 2011-09-01 at 14:10 +1000, David Gibson wrote:
> On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> > > On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > > > On
On Wed, 2011-09-07 at 13:58 +0200, Alexander Graf wrote:
> On 01.09.2011, at 21:50, Alex Williamson wrote:
>
> > Trying to move beyond talking about how VFIO should work to
> > re-writing the code. This is pre-alpha, known broken, will
> > probably crash your system bu
On Thu, 2011-09-08 at 10:52 +0300, Avi Kivity wrote:
> On 09/07/2011 09:55 PM, Konrad Rzeszutek Wilk wrote:
> > > If you don't know what to do here, say N.
> > > +
> > > +menuconfig VFIO_PCI
> > > +bool "VFIO support for PCI devices"
> > > +depends on VFIO&& PCI
> > >
On Fri, 2011-09-09 at 10:32 +0300, Michael S. Tsirkin wrote:
> On Fri, Sep 09, 2011 at 03:08:21AM -0400, Amos Kong wrote:
> > Hello all,
> >
> > I'm working on hotplug pci multifunction.
> >
> > 1. qemu cmdline:
> > ./x86_64-softmmu/qemu-system-x86_64 -snapshot -m 2000
> > /home/kvm_autotest_r
On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
> Based on the discussions over the last couple of weeks
> I have updated the device fd file layout proposal and
> tried to specify it a bit more formally.
>
> ===
>
> 1. Overview
>
Sorry for the delay, just getting back from LPC and some time off...
On Wed, 2011-09-07 at 10:52 -0400, Konrad Rzeszutek Wilk wrote:
> > +static long vfio_iommu_unl_ioctl(struct file *filep,
> > +unsigned int cmd, unsigned long arg)
> > +{
> > + struct vfio_iommu *vio
On Mon, 2011-09-19 at 14:37 -0500, Scott Wood wrote:
> On 09/19/2011 10:16 AM, Alex Williamson wrote:
> > On Fri, 2011-09-09 at 08:11 -0500, Stuart Yoder wrote:
> >> 2. Header
> >>
> >> The header is located at offset 0x0 in the device fd
> >> and h
On Wed, 2011-09-21 at 10:23 -0700, Erik Flister wrote:
> i posted this to virt-tools but got no replies, hoping you guys can help me.
> :)
>
> >>>AMD
> phenom II X6 1075T proc
> >>>ASUS M4A87TD mobo
Google says this is an AMD 870 chipset, so you do not have AMD IOMMU
(AMD-Vi) support :(
> >>>
Assigned device MSI-X support hasn't been working, this fixes
it. I believe this should also fix:
https://bugs.launchpad.net/qemu/+bug/830558
Thanks,
Alex
---
Alex Williamson (2):
pci-assign: Fix MSI-X registration
pci-assign: Re-order initfn for memory API
hw/d
We now need to scan PCI capabilities and setup an MSI-X page
before we walk the device resources since the overlay is now
setup during init instead of at the first mapping by the guest.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 16
1 files changed, 8
V_IRQ indicates more than just MSI,
let's just revert c4525754 and replace it with a sanity check that
we need KVM_CAP_ASSIGN_DEV_IRQ if the device supports any kind of
interrupt (which is still mostly paranoia).
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 13 +
1 fil
on it for older kernels. Maybe
some day we'll draw a line in the sand and be able to use it.
Thanks,
Alex
---
Alex Williamson (2):
pci-assign: Fix MSI-X capability test
pci-assign: Re-order initfn for memory API
hw/device-assignment.c | 24 +++-
1 files ch
We now need to scan PCI capabilities and setup an MSI-X page
before we walk the device resources since the overlay is now
setup during init instead of at the first mapping by the guest.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 19 +++
1 files changed, 11
LT if the call
exists.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 137c409..f0a6ca9 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignm
On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
> Am 26.09.2011 um 09:51 schrieb David Gibson :
>
> > On Fri, Sep 09, 2011 at 08:11:54AM -0500, Stuart Yoder wrote:
> >> Based on the discussions over the last couple of weeks
> >> I have updated the device fd file layout proposal and
> >> t
On Mon, 2011-09-26 at 15:03 -0500, Stuart Yoder wrote:
> >
> > The other obvious possibility is a pure ioctl interface. To match what
> > this proposal is trying to describe, plus the runtime interfaces, we'd
> > need something like:
> >
> > /* :0 - PCI devices, :1 - Devices path device, 63:2 - re
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
> On 09/26/2011 01:34 PM, Alex Williamson wrote:
> > The other obvious possibility is a pure ioctl interface. To match what
> > this proposal is trying to describe, plus the runtime interfaces, we'd
> > need something
On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote:
> On 09/26/2011 07:45 PM, Alex Williamson wrote:
> > On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
> >> On 09/26/2011 01:34 PM, Alex Williamson wrote:
> >>> /* Reset the device */
> >>> #de
it's
> PCIe Cap struct version is 0, which now fails device assignment
> due to the else fallout, where before, it would blissfully work.
>
> Add a quirk if version=0, & intel-82599, set size to version 2 struct.
>
> Signed-off-by: Donald_Dutile
Ugh.
Acked-by: Alex W
On Fri, 2011-09-30 at 18:46 +1000, David Gibson wrote:
> On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
> > On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
> > > Am 26.09.2011 um 09:51 schrieb David Gibson :
> [snip]
> > > Also, if you can
On Fri, 2011-09-30 at 10:37 -0600, Alex Williamson wrote:
> On Fri, 2011-09-30 at 18:46 +1000, David Gibson wrote:
> > On Mon, Sep 26, 2011 at 12:34:52PM -0600, Alex Williamson wrote:
> > > On Mon, 2011-09-26 at 12:04 +0200, Alexander Graf wrote:
> > > > Am 26.09.2011
ddr <= r_dev->msix_table_addr &&
> -real_region->base_addr + real_region->size >=
> +real_region->base_addr + real_region->size >
> r_dev->msix_table_addr) {
> int offset = r_dev->msix_table_addr
On Thu, 2011-10-27 at 10:56 +0800, Ren, Yongjie wrote:
> Hi,
> When doing device assignment with qemu and kvm upstream, I met "error:
> requires KVM support".
> Please also refer to the bug in qemu bugzilla.
> https://bugs.launchpad.net/qemu/+bug/882358
>
> qemu.git commit:8843cf40c0f482949e6a
On Wed, 2011-11-02 at 13:26 +0800, Kai Huang wrote:
> Hi,
>
> In case of direct io, without the interrupt remapping in IOMMU (intel
> VT-d or AMD IOMMU), hypervisor needs to inject interrupt for guest
> when the guest is scheduled to specific CPU. At the beginning I
> thought with IOMMU's interrup
On Tue, 2011-11-08 at 20:17 -0800, Aaron Fabbri wrote:
> I'm going to send out chunks of comments as I go over this stuff. Below
> I've covered the documentation file and vfio_iommu.c. More comments coming
> soon...
>
> On 11/3/11 1:12 PM, "Alex Williamson" w
On Wed, 2011-11-09 at 02:11 -0600, Christian Benvenuti (benve) wrote:
> I have not gone through the all patch yet, but here are
> my first comments/questions about the code in vfio_main.c
> (and pci/vfio_pci.c).
Thanks! Comments inline...
> > -Original Message-
> >
On Wed, 2011-11-09 at 15:08 -0600, Christian Benvenuti (benve) wrote:
> > > > +
> > > > +struct vfio_group {
> > > > + dev_t devt;
> > > > + unsigned intgroupid;
> > >
> > > This groupid is returned by the device_group callback you recently
> > added
> > >
On Wed, 2011-11-09 at 18:57 -0600, Christian Benvenuti (benve) wrote:
> Here are few minor comments on vfio_iommu.c ...
Sorry, I've been poking sticks at trying to figure out a clean way to
solve the force vfio driver attach problem.
> > diff --git a/drivers/vfio/vfio_iommu.c b/drivers/vfio/vfio_
On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > +Many modern system now provide DMA and interrupt remapping facilities
> > +to help ensure I/O devices behave within the boundaries they've been
> > +allotted. This
On Mon, 2011-11-14 at 13:54 -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> > On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > > + for (i = 0; i < npage; i++, iova += PAGE_SIZE, vaddr += PAGE_SIZE) {
> > > +
On Fri, 2011-11-11 at 16:22 -0600, Christian Benvenuti (benve) wrote:
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 11, 2011 10:04 AM
> > To: Christian Benvenuti (benve)
> > Cc: chr...@sou
On Mon, 2011-11-14 at 13:54 -0700, Alex Williamson wrote:
> On Fri, 2011-11-11 at 18:14 -0600, Scott Wood wrote:
> > On 11/03/2011 03:12 PM, Alex Williamson wrote:
> > > + int (*get)(void *);
> > > + void(*put)(void *);
> > &
On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> > new file mode 100644
> > index 000..5866896
> > --- /dev/null
>
unable to reproduce. An 82576 VF works just fine
in a Windows 2008 guest with this patch series. Thanks,
Alex
---
Alex Williamson (6):
pci-assign: Harden I/O port test
pci-assign: Remove bogus PCIe lnkcap wmask setting
pci-assign: Fix PCIe lnkcap
pci-assign: Fix PCI_EXP_FLAGS_T
We're destroying the memory container before we remove the
subregions it holds. This fixes:
https://bugs.launchpad.net/qemu/+bug/875723
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/d
The old_portio structure seems broken. Throw it away and
switch to the new style. This was hitting an assert when
trying to make use of I/O port regions.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 103
1 files changed, 35
Coverity found that we're doing (uint16_t)type & 0xf0 >> 8.
This is obviously always 0x0, so our attempt to filter out
some device types thinks everything is an endpoint. Fix
shift amount.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |2 +-
1 files changed, 1 i
Another Coverity found issue, lnkcap is a 32bit register and
we're masking bits 16 & 17. Fix to uin32_t.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-ass
All the fields of lnkcap are read-only and this is setting it
with mask values from LNKCTL. Just below it, we indicate
link control is read only, so this appears to be a stray
chunk left in from development. Trivial comment fix while
we're here.
Signed-off-by: Alex Williamson
---
hw/d
Markus Armbruster points out that we're missing a < 0 check
from pread while trying to probe for pci-sysfs io-port
resource support. We don't expect a short read, but we
should harden the test to abort if we get one so we're not
potentially looking at a stale errno.
S
On Tue, 2011-11-15 at 16:29 -0600, Scott Wood wrote:
> On 11/15/2011 03:40 PM, Aaron Fabbri wrote:
> >
> >
> >
> > On 11/15/11 12:10 PM, "Scott Wood" wrote:
> >
> >> On 11/15/2011 12:34 AM, David Gibson wrote:
> >
> +static int allow_unsafe_intrs;
> +module_param(allow_unsafe_intrs
On Wed, 2011-11-16 at 11:52 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 11, 2011 at 03:10:56PM -0700, Alex Williamson wrote:
> > > > +
> > > > +Regions are described by a struct vfio_region_info, which is retrieved
> > > > by
> &
On Wed, 2011-11-16 at 11:47 -0600, Scott Wood wrote:
> On 11/11/2011 04:10 PM, Alex Williamson wrote:
> >
> > Thanks Konrad! Comments inline.
> >
> > On Fri, 2011-11-11 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Nov 03, 2011 at 02:12:24PM -0600
On Thu, 2011-11-17 at 11:02 +1100, David Gibson wrote:
> On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> > On Tue, 2011-11-15 at 17:34 +1100, David Gibson wrote:
> > > On Thu, Nov 03, 2011 at 02:12:24PM -0600, Alex Williamson wrote:
> > > > +
On Mon, 2011-11-21 at 13:47 +1100, David Gibson wrote:
> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> > On Thu, 2011-11-17 at 11:02 +1100, David Gibson wrote:
> > > On Tue, Nov 15, 2011 at 11:01:28AM -0700, Alex Williamson wrote:
> > > > On
On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
>> Hmm, that might be cleaner than eliminating the size with just using
>> _IO(). So we might have something like:
>>
>> #define VFIO_IOMMU_MAP_DMA
On Tue, 2011-11-22 at 14:00 -0600, Scott Wood wrote:
> On 11/22/2011 01:16 PM, Alex Williamson wrote:
> > On Fri, Nov 18, 2011 at 2:09 PM, Scott Wood wrote:
> >> On Fri, Nov 18, 2011 at 01:32:56PM -0700, Alex Williamson wrote:
> >>> Ugh, I suppose you're think
On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
> Hi!
>
> I tried (successfully) to run it on POWER and while doing that I found some
> issues. I'll try to
> explain them in separate mails.
Great!
> IOMMU domain setup. On POWER, the linux drivers capable of DMA transfer want
> t
On Tue, 2011-11-29 at 13:01 +1100, Alexey Kardashevskiy wrote:
> Hi all,
>
> Another problem I hit on POWER - MSI interrupts allocation. The existing VFIO
> does not expect a PBH
> to support less interrupts that a device might request. In my case, PHB's
> limit is 8 interrupts
> while my test c
On Tue, 2011-11-29 at 15:34 +1100, Alexey Kardashevskiy wrote:
> Hi!
>
> On 29/11/11 14:46, Alex Williamson wrote:
> > On Tue, 2011-11-29 at 12:52 +1100, Alexey Kardashevskiy wrote:
> >> Hi!
> >>
> >> I tried (successfully) to run it on POWER and while
The vmsd code expects the fields structure to be properly terminated,
not NULL. An assigned device should never be saved or restored, and
recent qemu fixes to the no_migrate flag should ensure this, but let's
avoid setting the wrong precedent.
Signed-off-by: Alex Williamson
---
v2:
- C
On Tue, 2011-01-18 at 15:42 +0200, Michael S. Tsirkin wrote:
> Fix virtio-pci error handling in the mask notifiers: be careful to undo
> exactly what we did so far.
>
> Reported-by: Alex Williamson
> Signed-off-by: Michael S. Tsirkin
> ---
Looks right.
Acked-by: Alex William
On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote:
> On 2011-01-18 16:48, Anthony Liguori wrote:
> > On 01/18/2011 09:43 AM, Jan Kiszka wrote:
> >> On 2011-01-18 16:04, Anthony Liguori wrote:
> >>
> >>> On 01/18/2011 08:28 AM, Jan Kiszka wrote:
> >>>
> On 2011-01-12 11:31, Jan Kisz
On Tue, 2011-01-18 at 18:08 +0100, Jan Kiszka wrote:
> On 2011-01-18 18:02, Alex Williamson wrote:
> > On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote:
> >> On 2011-01-18 16:48, Anthony Liguori wrote:
> >>> On 01/18/2011 09:43 AM, Jan Kiszka wrote:
> >>
On Thu, 2011-01-20 at 17:35 +0200, Michael S. Tsirkin wrote:
> When MSI is off, each interrupt needs to be bounced through the io
> thread when it's set/cleared, so vhost-net causes more context switches and
> higher CPU utilization than userspace virtio which handles networking in
> the same threa
On Thu, 2011-01-20 at 18:23 -0600, Anthony Liguori wrote:
> On 01/20/2011 10:07 AM, Michael S. Tsirkin wrote:
> > On Thu, Jan 20, 2011 at 09:43:57AM -0600, Anthony Liguori wrote:
> >
> >> On 01/20/2011 09:35 AM, Michael S. Tsirkin wrote:
> >>
> >>> When MSI is off, each interrupt needs to
On Fri, 2011-01-21 at 11:55 +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 20, 2011 at 06:35:46PM -0700, Alex Williamson wrote:
> > On Thu, 2011-01-20 at 18:23 -0600, Anthony Liguori wrote:
> > > On 01/20/2011 10:07 AM, Michael S. Tsirkin wrote:
> > > > On Thu, Ja
;m not terribly happy with the solution in this series, it doesn't
provide any guarantees whether a cpu_register_physical_memory() will
succeed, only slightly better educated guesses.
Are there better ideas how we could solve this? Thanks,
Alex
---
Alex Williamson (2):
device-assignme
ce to successfully map memory.
Signed-off-by: Alex Williamson
---
kvm-all.c | 16
kvm.h |2 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 2f203dd..4fe3631 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -96,6 +96,22 @@ static KV
201 - 300 of 2367 matches
Mail list logo
