Web Master#8207;
Your e-mail has reached its set quota, Copy and paste the link below and fill requested details to avoid losing your account. http://tutorias.vervebogota.com/forms/forms/form1.html Thanks For Co-operating with Us. Copyright (c) 2014 Webmaster Administrator -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] vfio: Use new interfaces for MSI/MSI-X enablement
On Fri, 2014-01-10 at 08:42 +0100, Alexander Gordeev wrote:
Signed-off-by: Alexander Gordeev agord...@redhat.com
Thanks for the changes.
Acked-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/pci/vfio_pci_intrs.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 641bc87..4a9db1d 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -482,15 +482,19 @@ static int vfio_msi_enable(struct vfio_pci_device
*vdev, int nvec, bool msix)
for (i = 0; i nvec; i++)
vdev-msix[i].entry = i;
- ret = pci_enable_msix(pdev, vdev-msix, nvec);
- if (ret) {
+ ret = pci_enable_msix_range(pdev, vdev-msix, 1, nvec);
+ if (ret nvec) {
+ if (ret 0)
+ pci_disable_msix(pdev);
kfree(vdev-msix);
kfree(vdev-ctx);
return ret;
}
} else {
- ret = pci_enable_msi_block(pdev, nvec);
- if (ret) {
+ ret = pci_enable_msi_range(pdev, 1, nvec);
+ if (ret nvec) {
+ if (ret 0)
+ pci_disable_msi(pdev);
kfree(vdev-ctx);
return ret;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
High CPU use on host by idle Windows 7 guest
Hi, I have gotten Windows 7 to install and boot on KVM now, but now I'm having another problem: The qemu process that the Windows guest is running in is constantly using about 27% of one cpu core when idle (more when not, obviously). This is a fresh install of Windows 7 Professional with SP1 done in the same qemu virtual machine that it is currently running in, with virtio-scsi for disk connectivity and virtio-net for network, using the signed guest drivers found here: http://www.linux-kvm.org/page/Windows7Install There is nothing else installed on this Windows installation. (I have seen the same problem with another win7 vm with sata and e1000, though.) After some googling, I found a hint to disable the hpet timer to reduce the problem. This didn't work for me, though, the idle cpu use rose to over 60% instead. Another post suggested disabling acpi and/or apic, but that rendered Windows unable to boot up. This is happening with qemu 1.7 and linux kernel 3.12.6 using a SandyBridge host cpu. Qemu has been started with libvirt, the commandline looks like this: LC_ALL=C PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin HOME=/ USER=root QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name win7_master2,process=qemu:win7_master2 -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid, +pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi, +ds,+vme -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid a10e5a00-b1a4-e94d-c5a9-c3079834b400 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7_master2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/virtual_disks/win7_master2.img,if=none,id=drive-virtio- disk0,format=qcow2,cache=none -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive file=/virtual_disks/virtio- win-0.1-74.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw,cache=none - device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/virtual_disks/Win7STICK1_c.iso,if=none,id=drive- ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive- ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:e1:31:22,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl- vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0- codec0,bus=sound0.0,cad=0 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x7 Does anybody have an idea what's going wrong here? A linux guest (CentOS 6) on the same host will not use more than 1% cpu when idle. Regards, Guido -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))
I'm using the SuperMicro X10SAT, kernel 3.13-rc5, with ACS override on Intel root ports. I'm trying to pass several devices to the same guest: 01:00.0 -- [1002:68be] Radeon HD 5750 01:00.1 -- [1002:aa58] HDMI Audio (not really needed) 07:04.0 -- [13f6:8788] Xonar D1/DX sound card, behind PEX8112 09:00.0 -- [1912:0014] Renesas uPD720201 (USB 3.0) When trying to start qemu with various combinations of those devices: vfio: Error: Failed to setup INTx fd: Device or resource busy Sound card conflicts with HDMI audio: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. (vfio-intx(:01:00.1)) USB controller conflicts with video card: genirq: Flags mismatch irq 16. (vfio-intx(:09:00.0)) vs. (vfio-intx(:01:00.0)) On the ArchLinux forums, I was told that this means each device wants the interrupt line to itself. Oddly, the host locks up if I launch Xorg with 'radeon' and 'snd-virtuoso' both loaded. (Primary video is the Intel graphics.) These devices all work fine together using pci-assign, but pci-assign requires ejecting the Radeon before VM shutdown. VFIO allows me to start the VM if I forward only the sound card and the video card, but I really need the USB controller, as well. What can I do to forward those three devices via VFIO? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
set_pte_at_notify regression
Hi, It look like commit 6bdb913f0a70a4dfb7f066fb15e2d6f960701d00 break the semantic of set_pte_at_notify. The change of calling first to mmu_notifier_invalidate_range_start, then to set_pte_at_notify, and then to mmu_notifier_invalidate_range_end not only increase the amount of locks kvm have to take and release by factor of 3, but in addition mmu_notifier_invalidate_range_start is zapping the pte entry from kvm, so when set_pte_at_notify get called, it doesn`t have any spte to set and it acctuly get called for nothing, the result is increasing of vmexits for kvm from both do_wp_page and replace_page, and broken semantic of set_pte_at_notify. Thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: set_pte_at_notify regression
Hi!
On Fri, Jan 10, 2014 at 06:38:06PM +0200, Izik Eidus wrote:
It look like commit 6bdb913f0a70a4dfb7f066fb15e2d6f960701d00 break the
semantic of set_pte_at_notify.
The change of calling first to mmu_notifier_invalidate_range_start, then
to set_pte_at_notify, and then to mmu_notifier_invalidate_range_end
not only increase the amount of locks kvm have to take and release by
factor of 3, but in addition mmu_notifier_invalidate_range_start is zapping
the pte entry from kvm, so when set_pte_at_notify get called, it doesn`t
have any spte to set and it acctuly get called for nothing, the result is
increasing of vmexits for kvm from both do_wp_page and replace_page, and
broken semantic of set_pte_at_notify.
Agreed.
I would suggest to change set_pte_at_notify to return if change_pte
was missing in some mmu notifier attached to this mm, so we can do
something like:
ptep = page_check_address(page, mm, addr, ptl, 0);
[..]
notify_missing = false;
if (... ) {
entry = ptep_clear_flush(...);
[..]
notify_missing = set_pte_at_notify(mm, addr, ptep, entry);
}
pte_unmap_unlock(ptep, ptl);
if (notify_missing)
mmu_notifier_invalidate_page_if_missing_change_pte(mm, addr);
and drop the range calls. This will provide sleepability and at the
same time it won't screw the ability of change_pte to update sptes (by
leaving those established by the time change_pte runs).
This assuming the mutex are going to stay mutex for anon_vma lock and
i_mmap_mutex as I hope. Otherwise the commit could be as well
reverted, it would be pointless then to try to keep the
invalidate_page call outside the PT lock if all other invalidate_page
calls are inside rmap spinlocks.
I think giving a runtime or compiler option to switch the locks to
spinlocks is just fine, cellphones I think would be better off with
those locks as spinlocks for example, but completely removing the
ability to run those locks as mutex even on server setups, doesn't
look a too attractive development to me. A build option especially
wouldn't be too painful to maintain. So I'd be positive for an update
like above to retain the sleeability feature but without harming
change_pte users like KVM anymore.
Thanks!
Andrea
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))
On Fri, 2014-01-10 at 08:23 -0800, Dana Goyette wrote: I'm using the SuperMicro X10SAT, kernel 3.13-rc5, with ACS override on Intel root ports. I'm trying to pass several devices to the same guest: 01:00.0 -- [1002:68be] Radeon HD 5750 01:00.1 -- [1002:aa58] HDMI Audio (not really needed) 07:04.0 -- [13f6:8788] Xonar D1/DX sound card, behind PEX8112 09:00.0 -- [1912:0014] Renesas uPD720201 (USB 3.0) When trying to start qemu with various combinations of those devices: vfio: Error: Failed to setup INTx fd: Device or resource busy Sound card conflicts with HDMI audio: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. (vfio-intx(:01:00.1)) USB controller conflicts with video card: genirq: Flags mismatch irq 16. (vfio-intx(:09:00.0)) vs. (vfio-intx(:01:00.0)) On the ArchLinux forums, I was told that this means each device wants the interrupt line to itself. Oddly, the host locks up if I launch Xorg with 'radeon' and 'snd-virtuoso' both loaded. (Primary video is the Intel graphics.) These devices all work fine together using pci-assign, but pci-assign requires ejecting the Radeon before VM shutdown. VFIO allows me to start the VM if I forward only the sound card and the video card, but I really need the USB controller, as well. What can I do to forward those three devices via VFIO? Change slots until the interrupts don't conflict, maybe there's an IO-APIC option you can enable in the BIOS, or get devices that properly support PCI2.3 INTx disable. pci-assign tries to work around this by using MSI to emulate INTx, but I'm not convinced that this doesn't create more problems than it solves or I'd try to do the same with vfio. The Xorg problem might also suggest there's an existing interrupt routing problem on the system. It is surprising that you have so many devices that doesn't support INTx disable, can you try running this script on them: #!/bin/sh # Usage $0 PCI device, ex: 9:00.0 INTX=$(( 0x400 )) ORIG=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $ORIG )) -ne 0 ]; then echo INTx disable supported and enabled on $1 exit 0 fi NEW=$(printf %04x $(( $INTX | $ORIG ))) setpci -s $1 4.w=$NEW NEW=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $NEW )) -ne 0 ]; then echo INTx disable support available on $1 else echo INTx disable support NOT available on $1 fi NEW=$(printf %04x $ORIG) setpci -s $1 4.w=$NEW -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: vfio: silence GCC warning
On Fri, 2014-01-10 at 01:28 +0100, Paul Bolle wrote:
Building vfio.o triggers a GCC warning (when building for 32 bits x86):
arch/x86/kvm/../../../virt/kvm/vfio.c: In function 'kvm_vfio_set_group':
arch/x86/kvm/../../../virt/kvm/vfio.c:104:22: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
void __user *argp = (void __user *)arg;
^
Silence this warning by casting arg to unsigned long.
argp's current type, void __user *, is always casted to int32_t
__user *. So its type might as well be changed to int32_t __user *.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Acked-by: Alex Williamson alex.william...@redhat.com
---
Compile tested on both 32 and 64 bits x86. I've no KVM capable hardware
that is already running v3.13-rc* at hand. Besides, I wouldn't know how
to test the codepaths I'm changing here.
virt/kvm/vfio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index ca4260e..b4f9507 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -101,14 +101,14 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
long attr, u64 arg)
struct kvm_vfio *kv = dev-private;
struct vfio_group *vfio_group;
struct kvm_vfio_group *kvg;
- void __user *argp = (void __user *)arg;
+ int32_t __user *argp = (int32_t __user *)(unsigned long)arg;
struct fd f;
int32_t fd;
int ret;
switch (attr) {
case KVM_DEV_VFIO_GROUP_ADD:
- if (get_user(fd, (int32_t __user *)argp))
+ if (get_user(fd, argp))
return -EFAULT;
f = fdget(fd);
@@ -148,7 +148,7 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
long attr, u64 arg)
return 0;
case KVM_DEV_VFIO_GROUP_DEL:
- if (get_user(fd, (int32_t __user *)argp))
+ if (get_user(fd, argp))
return -EFAULT;
f = fdget(fd);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))
On 01/10/2014 09:33 AM, Alex Williamson wrote: On Fri, 2014-01-10 at 08:23 -0800, Dana Goyette wrote: I'm using the SuperMicro X10SAT, kernel 3.13-rc5, with ACS override on Intel root ports. I'm trying to pass several devices to the same guest: 01:00.0 -- [1002:68be] Radeon HD 5750 01:00.1 -- [1002:aa58] HDMI Audio (not really needed) 07:04.0 -- [13f6:8788] Xonar D1/DX sound card, behind PEX8112 09:00.0 -- [1912:0014] Renesas uPD720201 (USB 3.0) When trying to start qemu with various combinations of those devices: vfio: Error: Failed to setup INTx fd: Device or resource busy Sound card conflicts with HDMI audio: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. (vfio-intx(:01:00.1)) USB controller conflicts with video card: genirq: Flags mismatch irq 16. (vfio-intx(:09:00.0)) vs. (vfio-intx(:01:00.0)) On the ArchLinux forums, I was told that this means each device wants the interrupt line to itself. Oddly, the host locks up if I launch Xorg with 'radeon' and 'snd-virtuoso' both loaded. (Primary video is the Intel graphics.) These devices all work fine together using pci-assign, but pci-assign requires ejecting the Radeon before VM shutdown. VFIO allows me to start the VM if I forward only the sound card and the video card, but I really need the USB controller, as well. What can I do to forward those three devices via VFIO? Change slots until the interrupts don't conflict, maybe there's an IO-APIC option you can enable in the BIOS, or get devices that properly support PCI2.3 INTx disable. pci-assign tries to work around this by using MSI to emulate INTx, but I'm not convinced that this doesn't create more problems than it solves or I'd try to do the same with vfio. The Xorg problem might also suggest there's an existing interrupt routing problem on the system. It is surprising that you have so many devices that doesn't support INTx disable, can you try running this script on them: #!/bin/sh # Usage $0 PCI device, ex: 9:00.0 INTX=$(( 0x400 )) ORIG=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $ORIG )) -ne 0 ]; then echo INTx disable supported and enabled on $1 exit 0 fi NEW=$(printf %04x $(( $INTX | $ORIG ))) setpci -s $1 4.w=$NEW NEW=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $NEW )) -ne 0 ]; then echo INTx disable support available on $1 else echo INTx disable support NOT available on $1 fi NEW=$(printf %04x $ORIG) setpci -s $1 4.w=$NEW -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html After cold boot, without any attempts to run VM: Video card: INTx disable support available on 01:00.0 HDMI Audio: INTx disable supported and enabled on 01:00.1 USB: INTx disable supported and enabled on 09:00.0 PEX8112 (sound card sits behind this): INTx disable support available on 06:00.0) Sound card: INTx disable support NOT available on 07:04.0 If the sound card is the only one lacking this feature, then it seems odd that the USB controller is the one I have to remove for the VM to boot. The lspci -nnvv listing for my current sound card is quite sparse: 07:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788] Subsystem: ASUSTeK Computer Inc. Virtuoso 100 (Xonar D1) [1043:834f] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at c000 [disabled] [size=256] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- I'm willing to purchase a different sound card if that will fix the problem. Does lspci (-v or -vv) tell you if INTx Disable is available? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))
On Fri, 2014-01-10 at 12:18 -0800, Dana Goyette wrote: On 01/10/2014 09:33 AM, Alex Williamson wrote: On Fri, 2014-01-10 at 08:23 -0800, Dana Goyette wrote: I'm using the SuperMicro X10SAT, kernel 3.13-rc5, with ACS override on Intel root ports. I'm trying to pass several devices to the same guest: 01:00.0 -- [1002:68be] Radeon HD 5750 01:00.1 -- [1002:aa58] HDMI Audio (not really needed) 07:04.0 -- [13f6:8788] Xonar D1/DX sound card, behind PEX8112 09:00.0 -- [1912:0014] Renesas uPD720201 (USB 3.0) When trying to start qemu with various combinations of those devices: vfio: Error: Failed to setup INTx fd: Device or resource busy Sound card conflicts with HDMI audio: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. (vfio-intx(:01:00.1)) USB controller conflicts with video card: genirq: Flags mismatch irq 16. (vfio-intx(:09:00.0)) vs. (vfio-intx(:01:00.0)) On the ArchLinux forums, I was told that this means each device wants the interrupt line to itself. Oddly, the host locks up if I launch Xorg with 'radeon' and 'snd-virtuoso' both loaded. (Primary video is the Intel graphics.) These devices all work fine together using pci-assign, but pci-assign requires ejecting the Radeon before VM shutdown. VFIO allows me to start the VM if I forward only the sound card and the video card, but I really need the USB controller, as well. What can I do to forward those three devices via VFIO? Change slots until the interrupts don't conflict, maybe there's an IO-APIC option you can enable in the BIOS, or get devices that properly support PCI2.3 INTx disable. pci-assign tries to work around this by using MSI to emulate INTx, but I'm not convinced that this doesn't create more problems than it solves or I'd try to do the same with vfio. The Xorg problem might also suggest there's an existing interrupt routing problem on the system. It is surprising that you have so many devices that doesn't support INTx disable, can you try running this script on them: #!/bin/sh # Usage $0 PCI device, ex: 9:00.0 INTX=$(( 0x400 )) ORIG=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $ORIG )) -ne 0 ]; then echo INTx disable supported and enabled on $1 exit 0 fi NEW=$(printf %04x $(( $INTX | $ORIG ))) setpci -s $1 4.w=$NEW NEW=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $NEW )) -ne 0 ]; then echo INTx disable support available on $1 else echo INTx disable support NOT available on $1 fi NEW=$(printf %04x $ORIG) setpci -s $1 4.w=$NEW After cold boot, without any attempts to run VM: Video card: INTx disable support available on 01:00.0 HDMI Audio: INTx disable supported and enabled on 01:00.1 USB: INTx disable supported and enabled on 09:00.0 PEX8112 (sound card sits behind this): INTx disable support available on 06:00.0) Sound card: INTx disable support NOT available on 07:04.0 If the sound card is the only one lacking this feature, then it seems odd that the USB controller is the one I have to remove for the VM to boot. Please report the output of: $ cat /sys/module/vfio_pci/parameters/nointxmask I don't understand why your flags are 0 for all the devices, only the sound card should have that. The lspci -nnvv listing for my current sound card is quite sparse: 07:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788] Subsystem: ASUSTeK Computer Inc. Virtuoso 100 (Xonar D1) [1043:834f] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at c000 [disabled] [size=256] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- I'm willing to purchase a different sound card if that will fix the problem. Does lspci (-v or -vv) tell you if INTx Disable is available? No, lspci only reports the state of the DisINTx bit, not whether it's supported. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))
On 01/10/2014 01:12 PM, Alex Williamson wrote: On Fri, 2014-01-10 at 12:18 -0800, Dana Goyette wrote: On 01/10/2014 09:33 AM, Alex Williamson wrote: On Fri, 2014-01-10 at 08:23 -0800, Dana Goyette wrote: I'm using the SuperMicro X10SAT, kernel 3.13-rc5, with ACS override on Intel root ports. I'm trying to pass several devices to the same guest: 01:00.0 -- [1002:68be] Radeon HD 5750 01:00.1 -- [1002:aa58] HDMI Audio (not really needed) 07:04.0 -- [13f6:8788] Xonar D1/DX sound card, behind PEX8112 09:00.0 -- [1912:0014] Renesas uPD720201 (USB 3.0) When trying to start qemu with various combinations of those devices: vfio: Error: Failed to setup INTx fd: Device or resource busy Sound card conflicts with HDMI audio: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. (vfio-intx(:01:00.1)) USB controller conflicts with video card: genirq: Flags mismatch irq 16. (vfio-intx(:09:00.0)) vs. (vfio-intx(:01:00.0)) On the ArchLinux forums, I was told that this means each device wants the interrupt line to itself. Oddly, the host locks up if I launch Xorg with 'radeon' and 'snd-virtuoso' both loaded. (Primary video is the Intel graphics.) These devices all work fine together using pci-assign, but pci-assign requires ejecting the Radeon before VM shutdown. VFIO allows me to start the VM if I forward only the sound card and the video card, but I really need the USB controller, as well. What can I do to forward those three devices via VFIO? Change slots until the interrupts don't conflict, maybe there's an IO-APIC option you can enable in the BIOS, or get devices that properly support PCI2.3 INTx disable. pci-assign tries to work around this by using MSI to emulate INTx, but I'm not convinced that this doesn't create more problems than it solves or I'd try to do the same with vfio. The Xorg problem might also suggest there's an existing interrupt routing problem on the system. It is surprising that you have so many devices that doesn't support INTx disable, can you try running this script on them: #!/bin/sh # Usage $0 PCI device, ex: 9:00.0 INTX=$(( 0x400 )) ORIG=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $ORIG )) -ne 0 ]; then echo INTx disable supported and enabled on $1 exit 0 fi NEW=$(printf %04x $(( $INTX | $ORIG ))) setpci -s $1 4.w=$NEW NEW=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX $NEW )) -ne 0 ]; then echo INTx disable support available on $1 else echo INTx disable support NOT available on $1 fi NEW=$(printf %04x $ORIG) setpci -s $1 4.w=$NEW After cold boot, without any attempts to run VM: Video card: INTx disable support available on 01:00.0 HDMI Audio: INTx disable supported and enabled on 01:00.1 USB: INTx disable supported and enabled on 09:00.0 PEX8112 (sound card sits behind this): INTx disable support available on 06:00.0) Sound card: INTx disable support NOT available on 07:04.0 If the sound card is the only one lacking this feature, then it seems odd that the USB controller is the one I have to remove for the VM to boot. Please report the output of: $ cat /sys/module/vfio_pci/parameters/nointxmask I don't understand why your flags are 0 for all the devices, only the sound card should have that. The lspci -nnvv listing for my current sound card is quite sparse: 07:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788] Subsystem: ASUSTeK Computer Inc. Virtuoso 100 (Xonar D1) [1043:834f] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at c000 [disabled] [size=256] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- I'm willing to purchase a different sound card if that will fix the problem. Does lspci (-v or -vv) tell you if INTx Disable is available? No, lspci only reports the state of the DisINTx bit, not whether it's supported. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Looks like I had 'nointxmask' set to 1 for some reason (in /etc/modprobe.d/custom.conf). With nointxmask NOT set, the conflict messages change: genirq: Flags mismatch irq 17. (vfio-intx(:07:04.0)) vs. 0080 (vfio-intx(:01:00.1)) The latter is the HDMI audio. Removing it from the VM allows the VM to start. It would still be nice for the message to say something more descriptive. The flag meanings are not obvious, and when both sides are the same, it doesn't seem like a mismatch.
