Re: [PATCH] PCI: Add Ralink RT2800 broken INTx masking quirk
Alex Williamson wrote: Passes pci_intx_mask_supported but continues to send interrupts as discovered through VFIO-based device assignment. http://www.spinics.net/lists/kvm/msg73738.html Signed-off-by: Alex Williamson alex.william...@redhat.com Tested-by: Andreas Hartmann andihartm...@01019freenet.de --- Depends on Jan's base patch for this quirk: http://www.spinics.net/lists/linux-pci/msg15516.html drivers/pci/quirks.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index cbb4358..178f494 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2940,6 +2940,8 @@ static void __devinit quirk_broken_intx_masking(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x0010, quirk_broken_intx_masking); +DECLARE_PCI_FIXUP_FINAL(0x1814, 0x0601, /* Ralink RT2800 802.11n PCI */ + quirk_broken_intx_masking); static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, struct pci_fixup *end) -- 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
[Bug 43347] New: KVM internal error . Suberror:1 when running PCI Hardware Compliance Test for system job
https://bugzilla.kernel.org/show_bug.cgi?id=43347 Summary: KVM internal error . Suberror:1 when running PCI Hardware Compliance Test for system job Product: Virtualization Version: unspecified Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: vipmike...@gmail.com Regression: No Version-Release number of selected component Linux MIke-Cao-Office 3.4.0 #2 SMP Wed Jun 6 11:11:55 CST 2012 x86_64 x86_64 x86_64 GNU/Linux Guest : windows server 2012 RC Steps. 1.Start windows server 2012 VM CLI:sudo upsteam-qemu-kvm -m 8G -smp 4 -cpu host,+x2apic,family=0xf -name system-test -uuid cc791a6f-91c8-494a-b7f5-37f169663775 -rtc base=utc,clock=host,driftfix=slew -drive file=windows_server_2012,if=none,id=drive-test,format=raw,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,id=test,drive=drive-test -netdev tap,id=test,vhost=on -device virtio-net-pci,netdev=test,id=ttt,mac=00:12:13:14:15:16 -vnc :1 -monitor stdio -drive file=8400.0.WINMAIN_WIN8RC.120518-1423_X64FRE_SERVER_EN-US-HRC_SSS_X64FRE_EN-US_DV5.ISO,if=none,id=drive-cdrom1,format=raw,media=cdrom -device ide-drive,id=cdrom1,drive=drive-cdrom1 -drive file=virtio-win.iso,if=none,id=drive-cdrom2,format=raw,media=cdrom -device ide-drive,id=cdrom2,drive=drive-cdrom2 2.install Microsfot HCK Client in the guest 3.running PCI Hardware Compliance Test for systems job in HCK Studio Actual Results: KVM internal error. Suberror: 1 emulation failure RAX=0c00 RBX=fa80067f4030 RCX=f8025b3b7e00 RDX=027dab43c2a5 RSI=f8025b3b7dd3 RDI=0003 RBP=f8025b08b949 RSP=f8025b08b8b8 R8 =000d R9 =0002 R10=fa80067f4030 R11=f8025b3b7dd3 R12=005a R13=fa80067f4078 R14=0c00 R15=0021 RIP=f80259ac122f RFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =002b 00c0f300 DPL=3 DS [-WA] CS =0010 00209b00 DPL=0 CS64 [-RA] SS =0018 00c09300 DPL=0 DS [-WA] DS =002b 00c0f300 DPL=3 DS [-WA] FS =0053 3c00 0040f300 DPL=3 DS [-WA] GS =002b f80259d6d000 00c0f300 DPL=3 DS [-WA] LDT= TR =0040 f8025b07f080 0067 8b00 DPL=0 TSS64-busy GDT= f8025b07e000 007f IDT= f8025b07e080 0fff CR0=80050031 CR2=f8a5c008 CR3=00187000 CR4=06f8 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0d01 Code=00 49 83 e0 1f f3 0f 6f 04 0a f3 0f 6f 4c 0a 10 48 83 c1 20 66 0f 7f 41 e0 66 0f 7f 49 f0 49 ff c9 75 e2 e9 4f ff ff ff 66 66 66 66 66 66 66 0f 1f 84 Additional info : processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping: 4 microcode: 0x11 cpu MHz: 1600.000 cache size: 8192 KB physical id: 0 siblings: 8 core id: 3 cpu cores: 4 apicid: 7 initial apicid: 7 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips: 5320.19 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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
[Bug 43347] KVM internal error . Suberror:1 when running PCI Hardware Compliance Test for system job
https://bugzilla.kernel.org/show_bug.cgi?id=43347 --- Comment #1 from Mike Cao vipmike...@gmail.com 2012-06-07 06:19:27 --- Created an attachment (id=73521) -- (https://bugzilla.kernel.org/attachment.cgi?id=73521) Screen dump when hit this issue . -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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] PCI: Add Ralink RT2800 broken INTx masking quirk
Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Kind regards and thank you, Andreas Alex Williamson wrote: Passes pci_intx_mask_supported but continues to send interrupts as discovered through VFIO-based device assignment. http://www.spinics.net/lists/kvm/msg73738.html Signed-off-by: Alex Williamson alex.william...@redhat.com --- Depends on Jan's base patch for this quirk: http://www.spinics.net/lists/linux-pci/msg15516.html drivers/pci/quirks.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index cbb4358..178f494 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2940,6 +2940,8 @@ static void __devinit quirk_broken_intx_masking(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x0010, quirk_broken_intx_masking); +DECLARE_PCI_FIXUP_FINAL(0x1814, 0x0601, /* Ralink RT2800 802.11n PCI */ + quirk_broken_intx_masking); static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, struct pci_fixup *end) -- 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
1.1 release?
Are there any issues with 1.1 release of qemu-kvm? The RCs were followed qemu RCs quite closely, but the final 1.1 is still not released, anything wrong with it? Thanks! /mjt -- 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: KVM entry failed, hardware error
On 06/06/2012 09:07 PM, Johannes Bauer wrote: On 06.06.2012 17:53, Avi Kivity wrote: # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Please retry with git://git.kernel.org/pub/scm/virt/kvm/kvm.git big-real-mode Same thing: $ uname -a Linux joequad 3.5.0-rc1-46053-gf2ebd42 #1 SMP PREEMPT Wed Jun 6 19:49:21 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc1-46053-gf2ebd42 root=/dev/sda1 ro kvm-intel.emulate_invalid_guest_state=1 QEmu hangs with 100% CPU. Is there anything I can try to be able to tell you *where* it hangs? add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip (for csbase substitute the second value for CS in 'info registers') Run info registers a few times and note whether eip changes or not. -- error compiling committee.c: too many arguments to function -- 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: 1.1 release?
On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? The RCs were followed qemu RCs quite closely, but the final 1.1 is still not released, anything wrong with it? Yes, there is a regression with IDE PIO that can hang a guest on boot. We don't think it's a data corruptor, but I'd rather see it fixed before a release. -- error compiling committee.c: too many arguments to function -- 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: 1.1 release?
On 07.06.2012 11:13, Avi Kivity wrote: On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? [] Yes, there is a regression with IDE PIO that can hang a guest on boot. Any pointers on this? I were testing 1.1-rc with various guests and it all works more or less okay so far, but I didn't try pio mode. We don't think it's a data corruptor, but I'd rather see it fixed before a release. Yes, that'd be nice. Thanks, /mjt -- 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: [Bug 43347] New: KVM internal error . Suberror:1 when running PCI Hardware Compliance Test for system job
On 06/07/2012 09:17 AM, bugzilla-dae...@bugzilla.kernel.org wrote: Linux MIke-Cao-Office 3.4.0 #2 SMP Wed Jun 6 11:11:55 CST 2012 x86_64 x86_64 Code=00 49 83 e0 1f f3 0f 6f 04 0a f3 0f 6f 4c 0a 10 48 83 c1 20 66 0f 7f 41 e0 66 0f 7f 49 f0 49 ff c9 75 e2 e9 4f ff ff ff 66 66 66 66 66 66 66 0f 1f 84 66 0f 7f 41 e0 movdqa %xmm0,-0x20(%rcx) But we have movdqa emulation in 3.4, it's 49597d8116ad. Something doesn't fit. -- error compiling committee.c: too many arguments to function -- 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: 1.1 release?
On 06/07/2012 10:19 AM, Michael Tokarev wrote: On 07.06.2012 11:13, Avi Kivity wrote: On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? [] Yes, there is a regression with IDE PIO that can hang a guest on boot. Any pointers on this? See the thread started by Yongjie Ren. I were testing 1.1-rc with various guests and it all works more or less okay so far, but I didn't try pio mode. The bios uses it. -- error compiling committee.c: too many arguments to function -- 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: [Qemu-devel] [PATCH v2 00/41] postcopy live migration
On 06/04/2012 03:37 PM, Anthony Liguori wrote: On 06/04/2012 05:57 PM, Isaku Yamahata wrote: After the long time, we have v2. This is qemu part. The linux kernel part is sent separatedly. Changes v1 - v2: - split up patches for review - buffered file refactored - many bug fixes Espcially PV drivers can work with postcopy - optimization/heuristic Patches 1 - 30: refactoring exsiting code and preparation 31 - 37: implement postcopy itself (essential part) 38 - 41: some optimization/heuristic for postcopy Intro = This patch series implements postcopy live migration.[1] As discussed at KVM forum 2011, dedicated character device is used for distributed shared memory between migration source and destination. Now we can discuss/benchmark/compare with precopy. I believe there are much rooms for improvement. [1] http://wiki.qemu.org/Features/PostCopyLiveMigration Usage = You need load umem character device on the host before starting migration. Postcopy can be used for tcg and kvm accelarator. The implementation depend on only linux umem character device. But the driver dependent code is split into a file. I tested only host page size == guest page size case, but the implementation allows host page size != guest page size case. The following options are added with this patch series. - incoming part command line options -postcopy [-postcopy-flagsflags] where flags is for changing behavior for benchmark/debugging Currently the following flags are available 0: default 1: enable touching page request example: qemu -postcopy -incoming tcp:0: -monitor stdio -machine accel=kvm - outging part options for migrate command migrate [-p [-n] [-m]] URI [prefault forward [prefault backword]] -p: indicate postcopy migration -n: disable background transferring pages: This is for benchmark/debugging -m: move background transfer of postcopy mode prefault forward: The number of forward pages which is sent with on-demand prefault backward: The number of backward pages which is sent with on-demand example: migrate -p -n tcp:dest ip address: migrate -p -n -m tcp:dest ip address: 32 0 TODO - benchmark/evaluation. Especially how async page fault affects the result. I don't mean to beat on a dead horse, but I really don't understand the point of postcopy migration other than the fact that it's possible. It's a lot of code and a new ABI in an area where we already have too much difficulty maintaining our ABI. Without a compelling real world case with supporting benchmarks for why we need postcopy and cannot improve precopy, I'm against merging this. Hi Anthony, The example is quite simple lets look at a 300G guest that is dirtying 10 percent of it memory every second. (for example SAP ...) Even if we have a 30G/s network we will need 1 second of downtime of this guest , many workload time out in this kind of downtime. The guests are getting bigger and bigger so for those big guest the only way to do live migration is using post copy. I agree we are losing reliability with post copy but we can try to limit the risk : - do a full copy of the guest ram (precopy) and than switch to post copy only for the updates - the user will use a private LAN ,maybe with redundancy which is much safer - maybe backup the memory to storage so in case of network failure we can recover In the end it is up to the user , he can decide what he is willing to risk. The default of course should always be precopy live migration, maybe we should even have a different command for post copy. In the end I can see some users that will have no choice but use post copy live migration or stop the guest in order to move them to another host. Regards, Orit Regards, Anthony Liguori -- 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: KVM handling external interrupts
kvm-ow...@vger.kernel.org wrote on 07/06/2012 03:12:55: From: sheng qiu herbert1984...@gmail.com To: kvm kvm@vger.kernel.org, Date: 07/06/2012 03:13 Subject: KVM handling external interrupts Sent by: kvm-ow...@vger.kernel.org 1 as we know, normally the external interrupt will cause VMexit and the hypervisor will inject a virtual interrupt if it is for guest. Then which irq will be injected (i mean the interrupt vector for indexing the guest IDT)? How does the KVM get to know about this (associate a host IRQ with a guest virtual IRQ)? For emulated/para-virtual devices: There is no direct 1-to-1 relation between a physical irq that caused an exit and a virtual irq injected to the guest. QEMU is responsible for emulating virtual devices, and will inject a virtual interrupt (via KVM) when the virtual hardware emulation (software) does so. Physical interrupts are always handled by the host linux kernel whenever they caused and exit (arrived in guest mode) or not (arrived in root mode). So, physical interrupts are always consumed by the host. For example, interrupts in the host might trigger some I/O callback or release a thread blocked due to sync I/O in QEMU but QEMU does not map physical interrupts to virtual interrupts. Then, depending on how QEMU emulates the virtual devices, it may device to inject a virtual interrupt after it finished handling an I/O operation (e.g. callback called) 2 if for assigned device to the guest, the hypervisor will deliver that IRQ to the guest. by tracing the code, i found the host IRQ is different with the guest's (i mean the interrupt vector). how the KVM configure which interrupt vector the guest should use? For device assignment: In this case you do have a 1-to-1 mapping between physical and virtual interrupts but they do NOT necessary use the same vector. The linux host kernel assigns a physical vector. The guest OS assigns a virtual vector. KVM knows the virtual vector the guest is using and then injects a corresponding virtual interrupt each time a physical interrupts arrives. In other words, KVM does a simple physical to virtual conversion of the vector number. 3 if we configure not exit on external interrupt by setting some field in VMCS, what will happen during the physical interrupts? will the CPU use the guest IDT for response interrupt? If so, can KVM redirect the CPU to use another IDT for guest (assuming modifying the IDTR)? Yes, that's exactly something we already did in a research project. You can read our paper published in ASPLOS 2012: ELI: Bare-metal performance for I/O virtualization ( http://dl.acm.org/citation.cfm?id=2151020dl=ACMcoll=DLCFID=86701665CFTOKEN=26302003 ) Note this is not so simple, there are many other issues you should consider. 4 where is the guest IDT located? it this configured by the qemu while initializing the vcpu and registers (include the IDTR)? The guest IDT is located in the guest address space and the guest setup the IDTR (pointer to the IDT) register. KVM is not involved. In other words, KVM does not touch/modify the IDT content or the IDTR. KVM simple uses the hardware support in the processor to virtualize the IDTR register (GUEST_IDTR). Offcourse, you can modify the logic and let KVM change the IDTR/IDT as we did. Regards, Abel Gordon IBM Research - Haifa -- 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: KVM handling external interrupts
On 2012-06-07 09:51, Abel Gordon wrote: 3 if we configure not exit on external interrupt by setting some field in VMCS, what will happen during the physical interrupts? will the CPU use the guest IDT for response interrupt? If so, can KVM redirect the CPU to use another IDT for guest (assuming modifying the IDTR)? Yes, that's exactly something we already did in a research project. You can read our paper published in ASPLOS 2012: ELI: Bare-metal performance for I/O virtualization ( http://dl.acm.org/citation.cfm?id=2151020dl=ACMcoll=DLCFID=86701665CFTOKEN=26302003 Interesting. Can you provide it publicly (or send a version privately)? ) Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? I'm still hoping that Intel/AMD will finally enable this in hardware, at least for MSIs. Providing direct injection for legacy line-base interrupts is likely not worth the silicon and bits (would require some hw-assisted IOAPIC instead of just a bit more APIC virtualization). Jan signature.asc Description: OpenPGP digital signature
[PATCH v2] PCI: Mark INTx masking support of Chelsio T310 10GbE NIC as broken
From: Jan Kiszka jan.kis...@siemens.com
According to
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91388
the T310 does not properly support INTx masking as it fails to keep the
PCI_STATUS_INTERRUPT bit updated once the interrupt is masked. Mark this
adapter as broken so that pci_intx_mask_supported won't report it as
compatible.
Tested-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v2:
- Fixed device ID to Alexey's report
- Added reference to the original report
drivers/pci/pci.c|3 +++
drivers/pci/quirks.c | 12
include/linux/pci.h |2 ++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 447e834..9ae517a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2876,6 +2876,9 @@ bool pci_intx_mask_supported(struct pci_dev *dev)
bool mask_supported = false;
u16 orig, new;
+ if (dev-broken_intx_masking)
+ return false;
+
pci_cfg_access_lock(dev);
pci_read_config_word(dev, PCI_COMMAND, orig);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 2a75216..28804f4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2929,6 +2929,18 @@ static void __devinit disable_igfx_irq(struct pci_dev
*dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
+/*
+ * Some devices may pass our check in pci_intx_mask_supported if
+ * PCI_COMMAND_INTX_DISABLE works though they actually do not properly
+ * support this feature.
+ */
+static void __devinit quirk_broken_intx_masking(struct pci_dev *dev)
+{
+ dev-broken_intx_masking = 1;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x0030,
+ quirk_broken_intx_masking);
+
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
{
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d8c379d..7ea6cf8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -324,6 +324,8 @@ struct pci_dev {
unsigned intis_hotplug_bridge:1;
unsigned int__aer_firmware_first_valid:1;
unsigned int__aer_firmware_first:1;
+ unsigned intbroken_intx_masking:1; /* device's INTx masking
+ support is not working */
pci_dev_flags_t dev_flags;
atomic_tenable_cnt; /* pci_enable_device has been called */
--
1.7.3.4
--
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: 1.1 release?
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
On Behalf Of Avi Kivity
Sent: Thursday, June 07, 2012 3:28 PM
To: Michael Tokarev
Cc: KVM list
Subject: Re: 1.1 release?
On 06/07/2012 10:19 AM, Michael Tokarev wrote:
On 07.06.2012 11:13, Avi Kivity wrote:
On 06/07/2012 10:10 AM, Michael Tokarev wrote:
Are there any issues with 1.1 release of qemu-kvm?
[]
Yes, there is a regression with IDE PIO that can hang a guest on boot.
Any pointers on this?
See the thread started by Yongjie Ren.
This bug is here.
https://bugs.launchpad.net/qemu/+bug/1002121
The latest new is: after reverting bef0fd59 in qemu-kvm.git, it can work fine.
For detailed info, please look at the thread with below subject.
Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...
I were testing 1.1-rc with various guests and it all works more or
less okay so far, but I didn't try pio mode.
The bios uses it.
--
error compiling committee.c: too many arguments to function
--
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
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH] kvm tools: Process virito blk requests in separate thread
Il 07/06/2012 03:38, Asias He ha scritto:
I never looked at the kvmtool code, but I think Asias has a point. If
the guest submits I/O to lots of devices, they would contend on the
single thread. There was a similar proof of concept patch for QEMU that
provided substantial benefit.
However, it sounds a bit wasteful to have the dedicated thread run with
a second eventfd. Would it be hard to just use the virtio-blk ioeventfd
directly?
Without this patch, we are already using the virtio-blk ioeventfd
which is being monitored in the shared ioeventfd__thread() thead.
Yes, I understood that. :) I'm wondering why it is still necessary to
monitor that eventfd in the shared thread. Perhaps you could optionally
skip the epoll registration/deregistration in ioeventfd__{add,del}_event.
Paolo
--
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: KVM handling external interrupts
On 2012-06-07 10:13, Jan Kiszka wrote: On 2012-06-07 09:51, Abel Gordon wrote: 3 if we configure not exit on external interrupt by setting some field in VMCS, what will happen during the physical interrupts? will the CPU use the guest IDT for response interrupt? If so, can KVM redirect the CPU to use another IDT for guest (assuming modifying the IDTR)? Yes, that's exactly something we already did in a research project. You can read our paper published in ASPLOS 2012: ELI: Bare-metal performance for I/O virtualization ( http://dl.acm.org/citation.cfm?id=2151020dl=ACMcoll=DLCFID=86701665CFTOKEN=26302003 Interesting. Can you provide it publicly (or send a version privately)? Sorry, should have googled first: http://www.mulix.org/pubs/eli/eli.pdf :) ) Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? My first feeling is that it's not easily upstreamable due to the need to fiddle with the host's IDT, specifically on VCPU task migration. But I need to read the requirements of this more carefully. Still interesting work! Jan I'm still hoping that Intel/AMD will finally enable this in hardware, at least for MSIs. Providing direct injection for legacy line-base interrupts is likely not worth the silicon and bits (would require some hw-assisted IOAPIC instead of just a bit more APIC virtualization). Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? Well, I let you read the paper first :) It will answer all these questions. In a nutshell, Complicated: that always depends who you ask and relative to what you consider something complicated. ELI changes some critical points in KVM. Unsolved issues: there are some issues solves in theory but not implemented Security holes: not if you are OK with the threat model we describe in the paper need paravirtualize the guest: no if you have x2APIC. -- 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: KVM entry failed, hardware error
On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) info registers EAX=23de EBX=0b70 ECX=0b90 EDX=0002 ESI=002523de EDI=0b84 EBP=146e ESP=146e EIP=08d7 EFL=0202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =23de 00023de0 f300 CS =2000 0002 f300 SS =23de 00023de0 f300 DS =23de 00023de0 f300 FS =0060 00023de0 9300 GS =0060 00023de0 9300 LDT= 00c0 TR =0040 feffd000 2088 8b00 GDT= 0001f000 007f IDT= CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= (qemu) x/20i 0x2 + $eip 0x000208d7: leave 0x000208d8: ret 0x000208d9: enter $0x0,$0x0 0x000208dd: push %ebp 0x000208df: push %ebx 0x000208e1: push %esi 0x000208e3: push %edi 0x000208e5: mov%esp,%ebx 0x000208e8: mov%ebx,%edi 0x000208eb: add$0x14,%edi 0x000208ef: addr32 mov (%edi),%eax 0x000208f3: mov$0x1480,%sp 0x000208f6: xor%bp,%bp 0x000208f8: movzwl %bp,%ebp 0x000208fc: movzwl %sp,%esp 0x00020900: push %ebx 0x00020902: push %eax 0x00020904: call 0x20919 0x00020907: add$0x4,%sp 0x0002090a: pop%ebx And this is where it came from and tries to return to: (qemu) x /8hx 0x23de0 + $esp 0002524e: 0x1474 0x092a 0x0001 0x 0x0907 0x4970 0x0002 0x0b70 (qemu) x/20i 0x2 + 0x92a - 0x15 0x00020915: pop%ebp 0x00020917: leave 0x00020918: ret 0x00020919: enter $0x0,$0x0 0x0002091d: mov0x1510,%ax 0x00020920: push %ax 0x00020921: and%ax,%ax 0x00020923: je 0x2092a 0x00020927: call 0x20871 0x0002092a: push %bx 0x0002092b: push %di 0x0002092c: push %si 0x0002092d: push %ds 0x0002092e: push %es 0x0002092f: push %bp 0x00020930: mov0x4(%bp),%eax 0x00020934: mov%ax,%bp 0x00020936: and$0xf,%bp 0x00020939: shr$0x4,%eax 0x0002093d: mov%ax,%ds Here's the whole function that causes the hangup: (qemu) x/39i 0x2 + 0x871 0x00020871: enter $0x0,$0x0 0x00020875: push %ebx 0x00020877: mov0x1510,%ax 0x0002087a: and%ax,%ax 0x0002087c: je 0x208d5 0x00020880: sgdtw 0x1500 0x00020885: sidtw 0x1508 0x0002088a: movw $0x0,0x1510 0x00020890: mov%cr0,%eax 0x00020893: mov%eax,0x1514 0x00020897: and$0x7ffe,%eax 0x0002089d: mov%eax,%cr0 0x000208a0: jmp0x208a5 0x000208a2: nop 0x000208a3: nop 0x000208a4: nop 0x000208a5: mov%cr3,%eax 0x000208a8: nop 0x000208a9: nop 0x000208aa: nop 0x000208ab: nop 0x000208ac: mov%eax,%cr3 0x000208af: pushw 0x1536 0x000208b3: pop%es 0x000208b4: mov$0x8c6,%bx 0x000208b7: mov0x1536,%ax 0x000208ba: mov%ax,%es:-0x2(%bx) 0x000208be: ljmp *%es:-0x4(%bx) 0x000208c2: (bad) 0x000208c3: or %al,(%bx,%si) 0x000208c5: and%ah,0x1534(%bx,%di) 0x000208c9: mov%ax,%ds 0x000208cb: mov%ax,%ss 0x000208cd: mov%ax,%es 0x000208cf: lidtw 0x14f8 0x000208d4: sti 0x000208d5: pop%ebx 0x000208d7: leave 0x000208d8: ret Best regards, Joe -- 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: KVM handling external interrupts
On 2012-06-07 11:55, Abel Gordon wrote: Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? Well, I let you read the paper first :) It will answer all these questions. I'm on it. Two general remarks so far: - At least the preemption timer is not common x86 architecture but can only be found in VT-x. You should mention that you are focusing on Intel. - You discuss interrupt delivery without stating that you have MSIs in mind. Some aspects may be helpful for legacy interrupts as well, but you obviously can't achieve exit-less operation there. Not an issue, should just be made clear. In a nutshell, Complicated: that always depends who you ask and relative to what you consider something complicated. ELI changes some critical points in KVM. Unsolved issues: there are some issues solves in theory but not implemented Security holes: not if you are OK with the threat model we describe in the paper The thread model looks sane, but I'm not feeling well with the let's poll the guest to see if it misbehaved solution. It should work but is a bit ugly. need paravirtualize the guest: no if you have x2APIC. ...and the guest makes use of it. This excludes older OSes. When did Windows start to use it? Jan signature.asc Description: OpenPGP digital signature
[PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit
EPT Dirty bit use bit 9 as Intel SDM definition, to avoid conflict, change PT_FIRST_AVAIL_BITS_SHIFT to 10. Signed-off-by: Xudong Hao xudong@intel.com Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com --- arch/x86/kvm/mmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 24dd43d..f5b996a 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -90,7 +90,7 @@ module_param(dbg, bool, 0644); #define PTE_PREFETCH_NUM 8 -#define PT_FIRST_AVAIL_BITS_SHIFT 9 +#define PT_FIRST_AVAIL_BITS_SHIFT 10 #define PT64_SECOND_AVAIL_BITS_SHIFT 52 #define PT64_LEVEL_BITS 9 -- 1.5.5 -- 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: KVM handling external interrupts
- You discuss interrupt delivery without stating that you have MSIs in mind. Some aspects may be helpful for legacy interrupts as well, but you obviously can't achieve exit-less operation there. Not an issue, should just be made clear. Can you eleborate on why exit-less operation cannot be achieved without MSI? Doesn't the VMCS flag to avoid exiting on external interrupts apply to any interrupts? Or something else won't work? In any case, you're right that our implementation and tests all used MSI. need paravirtualize the guest: no if you have x2APIC. ...and the guest makes use of it. This excludes older OSes. When did Windows start to use it? Iff you can't use x2APIC, and don't want to paravirtualize the guest, you still get exit-less interrupt *delivery*, which as we showed in the benchmarks, gets you more than half of the performance improvement (although with newer KVM's improvement in EOI emulation performance, the over-half improvement should be somewhat less pronounced). Nadav. -- 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: Virtual machine does not respond to keyboard input when guest OS idles for a while
On 07.06.2012, at 03:26, Fei K Chen wrote: hi everyone, This is Fei Chen from IBM Research China. I and my team are working on enabling qemu-kvm on IBM prism A2 processor. After guest OS booted up, we can run linux commands on bash, such as ls, dmesg. However, if we stop input and let the guest OS idle for a while, such as 15 seconds, the guest OS will not respond to keyboard input anymore. Since interrupt controller is not ready for virtual machine, our guest OS boots up with irqpoll argument. Is it possible that when guest OS idle, it will not trap into kvm, so kvm can not inject a timer interrupt to guest OS? Have you got the similar problems? It might be related to the way you implement idle. But without seeing the code, I can't tell too much there. We certainly can run VMs with IRQs for more than 15 seconds on other ppc platforms though :). Btw, is there anything keeping you from just reusing QEMU's MPIC code for IRQ delivery? Alex -- 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: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 12:02:31: Yes, that's exactly something we already did in a research project. You can read our paper published in ASPLOS 2012: ELI: Bare-metal performance for I/O virtualization ( http://dl.acm.org/citation.cfm? id=2151020dl=ACMcoll=DLCFID=86701665CFTOKEN=26302003 Interesting. Can you provide it publicly (or send a version privately)? Sorry, should have googled first: http://www.mulix.org/pubs/eli/eli.pdf :) np ;) Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? My first feeling is that it's not easily upstreamable due to the need to fiddle with the host's IDT, specifically on VCPU task migration. But I need to read the requirements of this more carefully. Still interesting work! You don't need to fiddle with the host's IDT, you need to fiddle with the shadow IDT and interrupt vector mapping/remapping. -- 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: KVM handling external interrupts
On 2012-06-07 12:34, Nadav Har'El wrote: - You discuss interrupt delivery without stating that you have MSIs in mind. Some aspects may be helpful for legacy interrupts as well, but you obviously can't achieve exit-less operation there. Not an issue, should just be made clear. Can you eleborate on why exit-less operation cannot be achieved without MSI? Doesn't the VMCS flag to avoid exiting on external interrupts apply to any interrupts? Or something else won't work? The guest needs to interact with the IOAPIC. And this resource is shared between host and guest. It can't be passed through. In any case, you're right that our implementation and tests all used MSI. need paravirtualize the guest: no if you have x2APIC. ...and the guest makes use of it. This excludes older OSes. When did Windows start to use it? Iff you can't use x2APIC, and don't want to paravirtualize Often, it is more about ... _can't_ paravirtualize. :) the guest, you still get exit-less interrupt *delivery*, which as we showed in the benchmarks, gets you more than half of the performance improvement (although with newer KVM's improvement in EOI emulation performance, the over-half improvement should be somewhat less pronounced). Yes, I understood this, and I think looking at direct delivery would be a good first step to check if this could eventually become an upstream feature. It should even be beneficial for legacy interrupts. Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
On 2012-06-07 12:47, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 12:02:31: Yes, that's exactly something we already did in a research project. You can read our paper published in ASPLOS 2012: ELI: Bare-metal performance for I/O virtualization ( http://dl.acm.org/citation.cfm? id=2151020dl=ACMcoll=DLCFID=86701665CFTOKEN=26302003 Interesting. Can you provide it publicly (or send a version privately)? Sorry, should have googled first: http://www.mulix.org/pubs/eli/eli.pdf :) np ;) Note this is not so simple, there are many other issues you should consider. Is it just complicated, not upstreamable, or are the unsolved issues like security holes or the need to paravirtualize the guest? My first feeling is that it's not easily upstreamable due to the need to fiddle with the host's IDT, specifically on VCPU task migration. But I need to read the requirements of this more carefully. Still interesting work! You don't need to fiddle with the host's IDT, you need to fiddle with the shadow IDT and interrupt vector mapping/remapping. Yes, but you need to sync the host IDT into the shadow table. This may require some hooks in generic code to avoid scanning the host table on each guest entry. BTW, the shadow IDT has to be put in the guest address space, right? So we need to make it read-only for the guest? Jan signature.asc Description: OpenPGP digital signature
Re: KVM entry failed, hardware error
On 06/07/2012 01:03 PM, Johannes Bauer wrote: On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) x/20i 0x2 + $eip 0x000208d7: leave Pretty straightforward, we need to emulate the leave instruction. I'll update the branch and notify you. -- error compiling committee.c: too many arguments to function -- 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: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 13:51:19: My first feeling is that it's not easily upstreamable due to the need to fiddle with the host's IDT, specifically on VCPU task migration. But I need to read the requirements of this more carefully. Still interesting work! You don't need to fiddle with the host's IDT, you need to fiddle with the shadow IDT and interrupt vector mapping/remapping. Yes, but you need to sync the host IDT into the shadow table. This may require some hooks in generic code to avoid scanning the host table on each guest entry. Well, the shadow IDT only needs to be synced with interrupts coming from assigned devices. The rest of the entries doesn't matter, they just generate an exception. Once they generate an exception, they are delivered through the host IDT. So, all you need to know are the vectors assigned to the guest to build the shadow IDT. BTW, the shadow IDT has to be put in the guest address space, right? So we need to make it read-only for the guest? Yes, the shadow IDT is mapped into the guest address space and write-protected in case a malicious guest tries to change it. In addition, you also need to write protect the guest IDT to catch any changes the guest could made that need to be reflected in the shadow IDT (e.g. handlers for assigned vectors or exceptions). However, this is a rare case and does not occur during normal execution. -- 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: KVM handling external interrupts
On 2012-06-07 12:51, Jan Kiszka wrote: BTW, the shadow IDT has to be put in the guest address space, right? So we need to make it read-only for the guest? Just found your solution: Append to a PCI bar. That's nasty. Better reserve some memory via e820. There is a paravirtual channel from QEMU to the BIOS to communicate such reservations. BTW, the IDTR holds a linear address, not a virtual one. Unless I misremember, there is no need to map the IDT via the page table. The processor will not consult it for reading its entries. Also, you do not discuss making the shadow table read-only in the guest address space. This should help enforcing some security properties, no? Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
On 2012-06-07 13:05, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 13:51:19: My first feeling is that it's not easily upstreamable due to the need to fiddle with the host's IDT, specifically on VCPU task migration. But I need to read the requirements of this more carefully. Still interesting work! You don't need to fiddle with the host's IDT, you need to fiddle with the shadow IDT and interrupt vector mapping/remapping. Yes, but you need to sync the host IDT into the shadow table. This may require some hooks in generic code to avoid scanning the host table on each guest entry. Well, the shadow IDT only needs to be synced with interrupts coming from assigned devices. The rest of the entries doesn't matter, they just generate an exception. Once they generate an exception, they are delivered through the host IDT. So, all you need to know are the vectors assigned to the guest to build the shadow IDT. Not totally true. If the host decides to allocate some new vector that collides with some guest usage, you need to rearrange the shadow IDT and the physical IRQ routing. So you need to track what the host does. Jan signature.asc Description: OpenPGP digital signature
Re: Virtual machine does not respond to keyboard input when guest OS idles for a while
On 2012-06-07 03:26, Fei K Chen wrote: hi everyone, This is Fei Chen from IBM Research China. I and my team are working on enabling qemu-kvm on IBM prism A2 processor. Just a note: Don't use qemu-kvm as basis, use upstream QEMU or qemu-kvm's uq/master branch (if you have generic kvm subsystem changes). qemu-kvm is an x86-only fork that is fading out. Jan signature.asc Description: OpenPGP digital signature
Re: 1.1 release?
List, That patch that is referenced in the bugzilla : ... after reverting bef0fd59 in qemu-kvm, this issue doesn't exist. ... That is the exact same patch I had problems with a few weeks ago in iSCSI. As it turned out, it was NOT that patch that was buggy, but it exposed bugs in the iscsi block driver that made all I/O sudddenly take 55ms when booting from the BIOS, thus making the boot process tkae forever, andd it looked hung with a black screen, doing one i/o at a time 55ms apart. See http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02716.html Maybe the backend used here has the same bug that I had in block/iscsi.c which was basically failing to call 'qemu_notify_event()' properly. Would be a weird coincidence otherwise since the symptoms are so similar, and they were both triggered by that same patch. I would check how the events are set up in the backend used here and check if perhaps that backend has the same bug iscsi had. regards ronnie sahlberg On Thu, Jun 7, 2012 at 6:38 PM, Ren, Yongjie yongjie@intel.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Thursday, June 07, 2012 3:28 PM To: Michael Tokarev Cc: KVM list Subject: Re: 1.1 release? On 06/07/2012 10:19 AM, Michael Tokarev wrote: On 07.06.2012 11:13, Avi Kivity wrote: On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? [] Yes, there is a regression with IDE PIO that can hang a guest on boot. Any pointers on this? See the thread started by Yongjie Ren. This bug is here. https://bugs.launchpad.net/qemu/+bug/1002121 The latest new is: after reverting bef0fd59 in qemu-kvm.git, it can work fine. For detailed info, please look at the thread with below subject. Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... I were testing 1.1-rc with various guests and it all works more or less okay so far, but I didn't try pio mode. The bios uses it. -- error compiling committee.c: too many arguments to function -- 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 -- 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: KVM handling external interrupts
On 2012-06-07 11:55, Abel Gordon wrote: Security holes: not if you are OK with the threat model we describe in the paper Back to this: I don't get your threat model completely. How should the guest be able to manipulate the shadow IDT if we a) mark it read-only in the host's page table that maps the guest physical memory and b) prevent via the IOMMU that any assigned devices can address this page via DMA? But even if we consider the IDT unsafe, what does that IDT limiting buy us? The guest can still mask interrupts above that limit via cli, no? Also, unless I misunderstood your suggestions, I wouldn't try to run normal interrupt handlers in NMI context. That's asking for lots of troubles or lots of code changes. So the only measures that save us from CPU hogging guests are the preemption timer and kicking via NMI. Or what am I missing? Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:10:32: BTW, the shadow IDT has to be put in the guest address space, right? So we need to make it read-only for the guest? Just found your solution: Append to a PCI bar. That's nasty. Better reserve some memory via e820. There is a paravirtual channel from QEMU to the BIOS to communicate such reservations. We will take a look at e820 and consider your suggestion, thanks! The PCI BAR worked well to obtain an unused and mapped memory area for unmodified guests. Nasty ? Well, as usual, depends who you ask and the alternatives you compare with. For us, it was an elegant and easy way to achieve the goal. BTW, the IDTR holds a linear address, not a virtual one. Unless I misremember, there is no need to map the IDT via the page table. The processor will not consult it for reading its entries. As I understand and as we noticed in our runs using ELI, the processor uses the page tables to translate the IDTR (linear address) into physical address (guest physical in this case). (1) Logical addresses are converted to linear addresses using segments (not relevant in our case) (2) Linear addresses are converted to physical addresses using page tables (this is our case) Am I missing something ? In your case, I assume, [virtual = logical] and [linear = linear] or you are using some different semantics ? Also, you do not discuss making the shadow table read-only in the guest address space. This should help enforcing some security properties, no? We discussed this shortly at the end of Section 4.2: ...To detect runtime changes to the guest IDT, the host also write-protects the shadow IDT page. Other security and isolation considerations are discussed in Section 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
Re: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:13:45: Well, the shadow IDT only needs to be synced with interrupts coming from assigned devices. The rest of the entries doesn't matter, they just generate an exception. Once they generate an exception, they are delivered through the host IDT. So, all you need to know are the vectors assigned to the guest to build the shadow IDT. Not totally true. If the host decides to allocate some new vector that collides with some guest usage, you need to rearrange the shadow IDT and the physical IRQ routing. So you need to track what the host does. Well, depends if you re-allocate the vector used by the guest or the vector used by the host. Anyway, I think we understand each other :) -- 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: KVM handling external interrupts
On 2012-06-07 13:51, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:13:45: Well, the shadow IDT only needs to be synced with interrupts coming from assigned devices. The rest of the entries doesn't matter, they just generate an exception. Once they generate an exception, they are delivered through the host IDT. So, all you need to know are the vectors assigned to the guest to build the shadow IDT. Not totally true. If the host decides to allocate some new vector that collides with some guest usage, you need to rearrange the shadow IDT and the physical IRQ routing. So you need to track what the host does. Well, depends if you re-allocate the vector used by the guest or the vector used by the host. Anyway, I think we understand each other :) KVM is just a subsystem of the Linux kernel, usually not involved in LAPIC vector allocations. Your suggestion would turn this around a bit. Not impossible, but expect some discussions. ;) Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:54:35: Well, depends if you re-allocate the vector used by the guest or the vector used by the host. Anyway, I think we understand each other :) KVM is just a subsystem of the Linux kernel, usually not involved in LAPIC vector allocations. Your suggestion would turn this around a bit. :) I think we will find long discussions around this type of statement since KVM was created... how many changes made to the Linux kernel were driven by KVM ? (e.g MMU notifies for guest memory swapping) I wrote this just to clarify my point of view. I don't want to start an endless discussion around Linux and KVM synergy, so let's not do that :) Not impossible, but expect some discussions. ;) Agree -- 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: KVM handling external interrupts
On 2012-06-07 13:49, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:10:32: BTW, the shadow IDT has to be put in the guest address space, right? So we need to make it read-only for the guest? Just found your solution: Append to a PCI bar. That's nasty. Better reserve some memory via e820. There is a paravirtual channel from QEMU to the BIOS to communicate such reservations. We will take a look at e820 and consider your suggestion, thanks! The PCI BAR worked well to obtain an unused and mapped memory area for unmodified guests. Nasty ? Well, as usual, depends who you ask and the alternatives you compare with. For us, it was an elegant and easy way to achieve the goal. It's nasty as it requires more interaction between KVM and the userspace hypervisor and relies on PCI, which has nothing to do with the x86 architecture. Consider you only want to forward non-PCI interrupts (e.g. the LAPIC timer) and have no assigned device... BTW, the IDTR holds a linear address, not a virtual one. Unless I misremember, there is no need to map the IDT via the page table. The processor will not consult it for reading its entries. As I understand and as we noticed in our runs using ELI, the processor uses the page tables to translate the IDTR (linear address) into physical address (guest physical in this case). (1) Logical addresses are converted to linear addresses using segments (not relevant in our case) (2) Linear addresses are converted to physical addresses using page tables (this is our case) Am I missing something ? In your case, I assume, [virtual = logical] and [linear = linear] or you are using some different semantics ? No, you are right, the descriptor tables run through paging as well. But how do you ensure that the shadow IDT is mapped where you expect it? How do you detect where it is mapped? That reminds me of our KVM VAPIC and the hoops that code has to jump through to ensure this just for 32-bit XP guests... Jan signature.asc Description: OpenPGP digital signature
Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...
On Wed, Jun 6, 2012 at 3:17 AM, Ren, Yongjie yongjie@intel.com wrote: -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, June 04, 2012 9:51 PM To: Ren, Yongjie Cc: Marcelo Tosatti; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 01.06.2012 10:31, schrieb Kevin Wolf: Am 01.06.2012 09:57, schrieb Ren, Yongjie: -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Sent: Thursday, May 31, 2012 4:28 AM To: Ren, Yongjie Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote: -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, May 21, 2012 11:30 PM To: Ren, Yongjie Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 21.05.2012 11:45, schrieb Ren, Yongjie: -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, May 21, 2012 5:05 PM To: Avi Kivity Cc: Ren, Yongjie; kvm@vger.kernel.org Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 21.05.2012 10:27, schrieb Avi Kivity: On 05/21/2012 06:34 AM, Ren, Yongjie wrote: Hi All, This is KVM upstream test result against kvm.git 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7, and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983. We found 1 new bug and 1 bug got fixed in the past two weeks. New issue (1): 1. disk error when guest boot up via qcow2 image https://bugs.launchpad.net/qemu/+bug/1002121 -- Should be a regression on qemu-kvm. Kevin, is this the known regression in qcow2 or something new? If the commit ID is right, it must be something new. The regression that Marcelo found was fixed in 54e68143. Yes, it's right. This should be a new regression. I looked at the comment of 54e68143, and found it was not related the issue I reported. The Launchpad bug refers to commit e54f008ef, which doesn't include this fix indeed. So was the test repeated with a more current qemu-kvm version after filing the bug in Launchpad, or is the commit ID in this mail wrong? Latest commit 3fd9fedb in qemu-kvm master tree still has this issue. And, the commit ID provided in Launchpad is correct. Can you please check if the bug exists in upstream qemu.git as well? This bug doesn't exist on upstream qemu.git with latest commit: fd4567d9. So, it should only exists on qemu-kvm tree. Please bisect manually (not using git bisect), with the attached list of commits. These are the qemu - qemu-kvm merge commits in the range described as bad/good. The 1st bad commit in your attached list is abc551bd More detailed info: 171d2f2249a360d7d623130d3aa991418c53716d good fd453a24166e36a3d376c9bc221e520e3ee425af good abc551bd456cf0407fa798395d83dc5aa35f6dbb bad 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad Thanks, this points to the qcow2 v3 changes. Let's try to find the exact culprit. I have rebased the qcow2 patches on top of that good merge (fd453a24). Please apply the attached mbox on top of this merge: git checkout fd453a24 git am qcow2v3.mbox You can then start a git bisect between your new HEAD and fd453a24. Another thing you could try is if reverting e82dabd and bef0fd59 fixes the problem for you. After reverting bef0fd59, it can work fine. I'm unable to reproduce this with qemu-kvm.git/master (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you 3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad. The RHEL 6 guest boots without any issues. My host kernel is Linux 3.2 (Debian 3.2.0-2-amd64). The guest is Linux 2.6.32-71.el6. Since the guest sees a disk read error, it may be useful to add printfs to hw/ide/core.c:ide_sector_read_cb(). Let's find out why the disk read is failing. Stefan -- 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: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:40:57: But even if we consider the IDT unsafe, what does that IDT limiting buy us? The limit lets you force an exit (#GP exception) whenever the shadow IDT is ok or not. In this case, you simple shadow the GUEST_IDTR register and not a memory area The guest can still mask interrupts above that limit via cli, no? So the only measures that save us from CPU hogging guests are the preemption timer and kicking via NMI. Or what am I missing? Nothing :) As we described in the paper, this is what we do to avoid this situation. -- 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: KVM handling external interrupts
On 2012-06-07 14:17, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 14:40:57: But even if we consider the IDT unsafe, what does that IDT limiting buy us? The limit lets you force an exit (#GP exception) whenever the shadow IDT is ok or not. In this case, you simple shadow the GUEST_IDTR register and not a memory area The guest can still mask interrupts above that limit via cli, no? So the only measures that save us from CPU hogging guests are the preemption timer and kicking via NMI. Or what am I missing? Nothing :) As we described in the paper, this is what we do to avoid this situation. So the other measures are redundant, right? They only seem to complicate the approach without any gain, that is my point. Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 15:11:24: Am I missing something ? In your case, I assume, [virtual = logical] and [linear = linear] or you are using some different semantics ? No, you are right, the descriptor tables run through paging as well. Txs. Now that you understand your mistake, the discussion will be simpler. But how do you ensure that the shadow IDT is mapped where you expect it? First, I assume, you will agree with us that using the e820 as you suggested doesn't help because we need mapped memory. How ? As we described in the paper, we use the PCI BAR to obtain mapped memory. Where ? Doesn't matter. We know the GPA of the BAR and just do a reverse translation to obtain the GVA. -- 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: KVM handling external interrupts
kvm-ow...@vger.kernel.org wrote on 07/06/2012 15:19:14: The guest can still mask interrupts above that limit via cli, no? So the only measures that save us from CPU hogging guests are the preemption timer and kicking via NMI. Or what am I missing? Nothing :) As we described in the paper, this is what we do to avoid this situation. So the other measures are redundant, right? They only seem to complicate the approach without any gain, that is my point. We described in the paper all the mechanisms we thought could be used. Which mechanisms are sufficient/preferable/simpler ? I think we are back to the KVM-Linux dependencies and whenever we are talking about hypervisors in general or a specific implementation for KVM. -- 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
[Autotest][PATCH 1/2] frontend: Replaces mod_python by mod_wsgi apache module
This patch also repairs bug with readonly_connection to mysql database. Signed-off-by: Jiří Župka jzu...@redhat.com --- apache/conf/django-directives| 49 + frontend/db/backends/afe/base.py | 11 frontend/frontend.wsgi | 32 3 files changed, 81 insertions(+), 11 deletions(-) create mode 100644 frontend/frontend.wsgi diff --git a/apache/conf/django-directives b/apache/conf/django-directives index ce6c5c7..79914a0 100644 --- a/apache/conf/django-directives +++ b/apache/conf/django-directives @@ -13,6 +13,10 @@ RewriteEngine On RewriteCond /usr/local/autotest/site-packages/django/contrib/admin/media -d RewriteRule /media/(css|img|js)(.*) /usr/local/autotest/site-packages/django/contrib/admin/media/$1/$2 +# Django 1.4 does change location of the admin css files +RewriteCond /usr/local/autotest/site-packages/django/contrib/admin/static/admin -d +RewriteRule /media/(css|img|js)(.*) /usr/local/autotest/site-packages/django/contrib/admin/static/admin/$1/$2 + RewriteCond /usr/lib/python2.4/site-packages/django/contrib/admin/media -d RewriteRule /media/(css|img|js)(.*) /usr/lib/python2.4/site-packages/django/contrib/admin/media/$1/$2 @@ -25,14 +29,37 @@ RewriteRule /media/(css|img|js)(.*) /usr/lib/python2.6/site-packages/django/cont RewriteCond /usr/lib/python2.7/site-packages/django/contrib/admin/media -d RewriteRule /media/(css|img|js)(.*) /usr/lib/python2.7/site-packages/django/contrib/admin/media/$1/$2 -Location ~ /(afe|new_tko)/server -SetHandler python-program -PythonHandler django.core.handlers.modpython -SetEnv DJANGO_SETTINGS_MODULE frontend.settings -PythonDebug On -# Force our own site-packages to be loaded by mod_python prior -# to mod_python's system python site-packages directory. -# This way our code can depend on library versions other than -# those available as packages on various OS distributions. -PythonPath ['/usr/local/autotest/site-packages', '/usr/local/autotest', '/usr/lib/python2.7/site-packages/autotest', '/usr/lib/python2.6/site-packages/autotest', '/usr/lib/python2.5/site-packages/autotest', '/usr/lib/python2.4/site-packages/autotest'] + sys.path -/Location +# Django 1.4 does change location of the admin css files +RewriteCond /usr/lib/python2.7/site-packages/django/contrib/admin/static/admin -d +RewriteRule /media/(css|img|js)(.*) /usr/lib/python2.7/site-packages/django/contrib/admin/static/admin/$1/$2 + +#Old configuration for mod_python. + +#Location ~ /(afe|new_tko)/server +#SetHandler python-program +#PythonHandler django.core.handlers.modpython +#SetEnv DJANGO_SETTINGS_MODULE frontend.settings +#PythonDebug On +## Force our own site-packages to be loaded by mod_python prior +## to mod_python's system python site-packages directory. +## This way our code can depend on library versions other than +## those available as packages on various OS distributions. +#PythonPath ['/usr/local/autotest/site-packages', '/usr/local/autotest', '/usr/lib/python2.7/site-packages/autotest', '/usr/lib/python2.6/site-packages/autotest', '/usr/lib/python2.5/site-packages/autotest', '/usr/lib/python2.4/site-packages/autotest'] + sys.path +#/Location + + +#New configuration for mod_swgi + +RewriteRule ^/(afe|new_tko)/server(.*)$ /$1/server$2 [QSA,PT,L] + +WSGISocketPrefix run/wsgi +#Thread have to be only one because there could be problem with readonly_connection. +WSGIDaemonProcess apache processes=10 threads=1 +WSGIProcessGroup apache + +WSGIScriptAliasMatch /(afe|new_tko)/server.* /usr/local/autotest/frontend/frontend.wsgi + +Directory /usr/local/autotest/frontend/ +Order allow,deny +Allow from all +/Directory diff --git a/frontend/db/backends/afe/base.py b/frontend/db/backends/afe/base.py index 067abac..64114b8 100644 --- a/frontend/db/backends/afe/base.py +++ b/frontend/db/backends/afe/base.py @@ -20,3 +20,14 @@ class DatabaseWrapper(MySQLDatabaseWrapper): self.creation = MySQLCreation(self) self.ops = DatabaseOperations() self.introspection = MySQLIntrospection(self) + +def _valid_connection(self): +if self.connection is not None: +if self.connection.open: +try: +self.connection.ping() +return True +except DatabaseError: +self.connection.close() +self.connection = None +return False diff --git a/frontend/frontend.wsgi b/frontend/frontend.wsgi new file mode 100644 index 000..ff1e54b --- /dev/null +++ b/frontend/frontend.wsgi @@ -0,0 +1,32 @@ +import os, sys + +try: + import autotest.common +except ImportError: + frontend_dir = os.path.dirname(sys.modules[__name__].__file__) + sys.path.insert(0, frontend_dir) + import common + sys.path.pop(0) + +path_list = ['/usr/local/autotest/site-packages', '/usr/local/autotest', +
Re: KVM entry failed, hardware error
On 06/07/2012 01:54 PM, Avi Kivity wrote: On 06/07/2012 01:03 PM, Johannes Bauer wrote: On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) x/20i 0x2 + $eip 0x000208d7: leave Pretty straightforward, we need to emulate the leave instruction. I'll update the branch and notify you. Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. -- error compiling committee.c: too many arguments to function -- 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: KVM handling external interrupts
On 2012-06-07 14:25, Abel Gordon wrote: Jan Kiszka jan.kis...@web.de wrote on 07/06/2012 15:11:24: Am I missing something ? In your case, I assume, [virtual = logical] and [linear = linear] or you are using some different semantics ? No, you are right, the descriptor tables run through paging as well. Txs. Now that you understand your mistake, the discussion will be simpler. But how do you ensure that the shadow IDT is mapped where you expect it? First, I assume, you will agree with us that using the e820 as you suggested doesn't help because we need mapped memory. How ? As we described in the paper, we use the PCI BAR to obtain mapped memory. Where ? Doesn't matter. We know the GPA of the BAR and just do a reverse translation to obtain the GVA. It remains a fragile approach: - host-side reverse translations may not return a stable result, thus may require to redo this step several times - the guest may decide to remove/disable the device you chose for appending the IDT - changing the real BAR size can confuse the guest, or it only maps what it requires of the real device That's why I consider it nasty. I'm wondering if redirecting (to different cores) or masking (at device/IOAPIC/LAPIC level) of non-guest interrupts and only relying on preemption timer/NMI isn't simpler. Then you wouldn't have to shadow the IDT. Jan signature.asc Description: OpenPGP digital signature
Re: KVM handling external interrupts
On 2012-06-07 14:32, Abel Gordon wrote: kvm-ow...@vger.kernel.org wrote on 07/06/2012 15:19:14: The guest can still mask interrupts above that limit via cli, no? So the only measures that save us from CPU hogging guests are the preemption timer and kicking via NMI. Or what am I missing? Nothing :) As we described in the paper, this is what we do to avoid this situation. So the other measures are redundant, right? They only seem to complicate the approach without any gain, that is my point. We described in the paper all the mechanisms we thought could be used. Which of them did you implement and validate so far? Which mechanisms are sufficient/preferable/simpler ? I think we are back to the KVM-Linux dependencies and whenever we are talking about hypervisors in general or a specific implementation for KVM. I don't think this depends on KVM vs. whatever hypervisor, these are pretty generic considerations. If you need the preemption timer for breaking out of cli anyway, why play tricks with off-limit vectors? NMIs can be useful to accelerate the preemption when some other core wants to deliver an IPI (to kick the target out of guest mode and to reenable interrupts, not to process them). Jan signature.asc Description: OpenPGP digital signature
[Bug 43347] KVM internal error . Suberror:1 when running PCI Hardware Compliance Test for system job
https://bugzilla.kernel.org/show_bug.cgi?id=43347 Avi Kivity a...@redhat.com changed: What|Removed |Added CC||a...@redhat.com --- Comment #2 from Avi Kivity a...@redhat.com 2012-06-07 15:13:18 --- 66 0f 7f 41 e0 movdqa %xmm0,-0x20(%rcx) But we have movdqa emulation in 3.4, it's 49597d8116ad. Something doesn't fit. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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: KVM entry failed, hardware error
On 07.06.2012 16:52, Avi Kivity wrote: Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. Progress! So now I'm on Linux joequad 3.5.0-rc1-46078-g54d5c7c #2 SMP PREEMPT Thu Jun 7 17:11:38 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux And see the following (kind of weird) behavior: I can boot up now. But it's bound to some condition: When not using -monitor stdio, I have the same behavior as before. When using -monitor stdio, it locks up occasionaly, but appears to resume operation whenever I type info registers. That way I was able to boot up (by entering about 50 times info registers, then it had left real mode and booted up normally). I was first a bit confused, but this is definitely what I'm seeing: Because of shutting down the VM I had put the guest in a Windows Recovery mode where a text-mode progress bar appears with the text Windows is loading files The bar locks up -- when I type info registers, it progresses about 2-4 characters and locks up again (until it's fully loaded, then it just works). Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. But I think we're getting somewhere! Thank you very much for your support already! Best regards, Joe -- 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
[PATCH v2] PCI: Add Ralink RT2800 broken INTx masking quirk
Passes pci_intx_mask_supported test but continues to send interrupts as discovered through VFIO-based device assignment. http://www.spinics.net/lists/kvm/msg73738.html Signed-off-by: Alex Williamson alex.william...@redhat.com Tested-by: Andreas Hartmann andihartm...@01019freenet.de --- v2: context-only respin for Jan's v2 patch Depends on Jan's patch: http://www.spinics.net/lists/linux-pci/msg15720.html drivers/pci/quirks.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 87b9edd..3681678 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2940,6 +2940,8 @@ static void __devinit quirk_broken_intx_masking(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x0030, quirk_broken_intx_masking); +DECLARE_PCI_FIXUP_FINAL(0x1814, 0x0601, /* Ralink RT2800 802.11n PCI */ + quirk_broken_intx_masking); static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, struct pci_fixup *end) -- 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] PCI: Add Ralink RT2800 broken INTx masking quirk
On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. Thanks, Alex -- 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] PCI: Add Ralink RT2800 broken INTx masking quirk
On 2012-06-07 19:05, Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. Thanks, Isn't this controllable on a per-device base from userspace (or is this what you mean)? That would nicely align to qemu-kvm's pci-assign share_intx property (and may allow to map pci-assign's user-visible interface to a vfio backend one day). Jan signature.asc Description: OpenPGP digital signature
Re: KVM entry failed, hardware error
On 06/07/2012 06:39 PM, Johannes Bauer wrote: On 07.06.2012 16:52, Avi Kivity wrote: Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. Progress! Great! So now I'm on Linux joequad 3.5.0-rc1-46078-g54d5c7c #2 SMP PREEMPT Thu Jun 7 17:11:38 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux And see the following (kind of weird) behavior: I can boot up now. But it's bound to some condition: When not using -monitor stdio, I have the same behavior as before. When using -monitor stdio, it locks up occasionaly, but appears to resume operation whenever I type info registers. That way I was able to boot up (by entering about 50 times info registers, then it had left real mode and booted up normally). I was first a bit confused, but this is definitely what I'm seeing: Because of shutting down the VM I had put the guest in a Windows Recovery mode where a text-mode progress bar appears with the text Windows is loading files The bar locks up -- when I type info registers, it progresses about 2-4 characters and locks up again (until it's fully loaded, then it just works). Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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] PCI: Add Ralink RT2800 broken INTx masking quirk
On Thu, 2012-06-07 at 19:18 +0200, Jan Kiszka wrote: On 2012-06-07 19:05, Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. Thanks, Isn't this controllable on a per-device base from userspace (or is this what you mean)? That would nicely align to qemu-kvm's pci-assign share_intx property (and may allow to map pci-assign's user-visible interface to a vfio backend one day). No, there's currently no per-device control of this from userspace with VFIO. It wouldn't be hard to make use of flags bits in the ioctls to support it, but I don't just want to move the blacklist from the kernel out to the user. Thanks, Alex -- 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: KVM entry failed, hardware error
On 07.06.2012 19:25, Avi Kivity wrote: Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. Doesn't seem to be right -- still got the same problem. I first bumped it up to 1300 and inserted debugging output to see how many cycles are actually spent in the loop. It enters the emulation mode so frequently (and leaves it again) that the dmesg buffer ran over (128kB). So I changed the debugging to give me the lowest cycle count that it ever has after the loop: handle_invalid_guest_state: emulation left, new low count 1295 handle_invalid_guest_state: emulation left, new low count 1292 handle_invalid_guest_state: emulation left, new low count 1291 handle_invalid_guest_state: emulation left, new low count 1245 Which means that it spends a maximum of 55 cycles in the loop (well below the original 130 even). So my change had no effect. Any other ideas maybe? Best regards, Joe -- 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: KVM entry failed, hardware error
On 07.06.2012 19:25, Avi Kivity wrote: Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. Okay, here's more clues. They're not exactly meaningful for me, but probably of interest to you. Besides the low count value after loop exit value, I've introduced two counters which both are incremented inside the loop. Also I've modified the loop to be one return only (i.e. ret = foobar; goto out instead of return). Then when I have a script which continuously echos info registers and pipe that output together with qemu, I get this startup: 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1295, total of 5 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1292, total of 13 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, 1293 iterations left, 15 emulated insn, loop low count 1292 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1291, total of 131214 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1245, total of 131269 emulated insns 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 25 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 300012 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1291 iterations left, 400013 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 500050 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 600059 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 700059 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 800059 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 900059 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 159 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, new loop low count 1228, total of 1030349 emulated insns 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1291 iterations left, 1100063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 1200063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 1300063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1245 iterations left, 1400113 emulated insn, loop low count 1228 2012-06-07 21:39:37 handle_invalid_guest_state: emulation left, 1245 iterations left, 1500145 emulated insn, loop low count 1228 After which it has booted up and does not emulate anymore. Note the maximum time spent in the loop is 72 iterations. But when I just start up and do not issue ANY info registers, I get the following output: 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1295, total of 5 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1292, total of 13 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, 1293 iterations left, 14 emulated insn, loop low count 1292 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1291, total of 131955 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1245, total of 132010 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, 1299 iterations left, 24 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 34 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 44 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 54 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 64 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 74 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left,
Re: KVM entry failed, hardware error
On 07.06.2012 21:46, Johannes Bauer wrote: In an infinite loop. Which looks to be as if it is continuously exiting after just one iteration (count at leave is 1299). Maybe I'll fiddle some more and am able to provide some insight (probably you already know what's going on, but it won't hurt I guess). Followup on that: I've shorted the debug output (so it doesn't get wrapped in mail and can be more easily read) and I've enumerated all five possible exists from the loop: 1. intr_window_requested (kvm_get_rflags(vmx-vcpu) X86_EFLAGS_IF) 2. err == EMULATE_DO_MMIO 3. err != EMULATE_DONE 4. signal_pending(current) 5. while loop exit And added that to the loop. When it hangs, it always exists by #1: higs: new low cnt 1295, 5 emu insns higs: new low cnt 1292, 13 emu insns higs: left count=1293, 12 emu insns, llc=1292, rsn=5 higs: new low cnt 1291, 135348 emu insns higs: new low cnt 1245, 135403 emu insns higs: new low cnt 1228, 183120 emu insns higs: left count=1291, 27 emu insns, llc=1228, rsn=5 higs: left count=1299, 37 emu insns, llc=1228, rsn=1 higs: left count=1299, 47 emu insns, llc=1228, rsn=1 higs: left count=1299, 57 emu insns, llc=1228, rsn=1 higs: left count=1299, 67 emu insns, llc=1228, rsn=1 higs: left count=1299, 77 emu insns, llc=1228, rsn=1 higs: left count=1299, 87 emu insns, llc=1228, rsn=1 higs: left count=1299, 97 emu insns, llc=1228, rsn=1 higs: left count=1299, 107 emu insns, llc=1228, rsn=1 higs: left count=1299, 117 emu insns, llc=1228, rsn=1 higs: left count=1299, 127 emu insns, llc=1228, rsn=1 higs: left count=1299, 137 emu insns, llc=1228, rsn=1 higs: left count=1299, 147 emu insns, llc=1228, rsn=1 higs: left count=1299, 157 emu insns, llc=1228, rsn=1 higs: left count=1299, 167 emu insns, llc=1228, rsn=1 higs: left count=1299, 177 emu insns, llc=1228, rsn=1 higs: left count=1299, 187 emu insns, llc=1228, rsn=1 higs: left count=1299, 197 emu insns, llc=1228, rsn=1 higs: left count=1299, 207 emu insns, llc=1228, rsn=1 higs: left count=1299, 217 emu insns, llc=1228, rsn=1 [...] If there's any more output I can provide to help you track down the problem at hand, please let me know. Best regards, Joe -- 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] PCI: Add Ralink RT2800 broken INTx masking quirk
Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. That's exactly what I meant. May I have please another question? Unfortunately I can't cleanly unmount filesystems during shutdown with your kernel (this problem doesn't happen with the patched 3.4 suse kernel). I applied your vfio-patches from your git-repository to an openSUSE 3.4 kernel (plus one other to get the patches applied): iommu_core:_pass_a_user-provided_token_to_fault_handlers.patch 0ca4120cbaeaa2aecdccc5043b309fe1808aae2a.patch [PATCH] pci: Add PCI DMA source ID quirk db47c1f7313ad863818261f62f1babaf0b564e55.patch [PATCH] pci: Add ACS validation utility a89edb6943102d4519860bca5671740c1b7364cc.patch [PATCH] pci: export pci_user functions for use by other drivers 38fdda7327b6cf50c1265a6332e94b97100aa10e.patch [PATCH] pci: Create common pcibios_err_to_errno cb6e045625e5a217df3cebcb4585b40cbcad6c96.patch [PATCH] pci: Misc pci_reg additions c6985f9b501903f5c707a1711fa53dc94c72f999.patch [PATCH] driver core: Add iommu_group tracking to struct device 581187e853620c52e4b78db643161cc3be2f3388.patch [PATCH] iommu: IOMMU Groups 635e48574089f4c8205a2fd7b1d85edd02344fe5.patch [PATCH] amd_iommu: Support IOMMU groups 37f2d6d5217fdd2facd9641b83fde683263adcaf.patch [PATCH] intel-iommu: Support IOMMU groups 351d849a51787140736e04f261ae9db09c980868.patch [PATCH] amd_iommu: Make use of DMA quirks and ACS checks in IOMMU 92eef0a72193ef8504eea10b4ccbdb2e1ee9f4b3.patch [PATCH] intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups dd2886fe0a8936d649a365162658406e7a18d274.patch [PATCH] iommu: Remove group_mf 6891b9a7d56841e592cfb444a7f4b2b02831f866.patch [PATCH] vfio: VFIO core 51b06ff680d8bc30d1bd627e2dd24641789be55d.patch [PATCH] vfio: Add documentation 4b36b306122a225d33e947e7f9e6d1117a4fb699.patch [PATCH] vfio: Type1 IOMMU implementation 91e4950e482b142dd9ab46f0ec386c5eed9f1470.patch [PATCH] vfio: Add PCI device driver PCI:_Mark_INTx_masking_support_of_Chelsio_T310_10GbE_NIC_as_broken.patch PCI:_Add_Ralink_RT2800_broken_INTx_masking_quirk.patch IRQF_ONESHOT.patch The VM does work as expected, but fglrx isn't happy any more (but worked fine with your kernel and works fine, too, with the unpatched suse 3.4 kernel). fglrx says: Jun 7 14:21:42 host kernel: [ 105.103610] [fglrx:firegl_cail_init] *ERROR* CAIL: CAILInitialize failed, error 1 Jun 7 14:21:42 host kernel: [ 105.103613] [fglrx:hal_init_asic] *ERROR* Failed to initialize ASIC. Jun 7 14:21:42 host kernel: [ 105.103645] [fglrx:firegl_init_pcie] *ERROR* Can not get FB size Jun 7 14:21:42 host kernel: [ 105.103653] [fglrx:IRQMGR_alloc_context] *ERROR* IRQMGR_GetExtensionSize returned 0 Jun 7 14:21:42 host kernel: [ 105.103654] [fglrx:irqmgr_wrap_initialize] *ERROR* Fail to allocate IRQMGR context! Jun 7 14:21:42 host kernel: [ 105.109151] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff32 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.109173] [fglrx:firegl_irq_enable] *ERROR* interrupt source 1000 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169073] [fglrx:firegl_irq_enable] *ERROR* interrupt source 6001 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169107] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff2c is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169125] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff4e is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169142] [fglrx:firegl_irq_enable] *ERROR* interrupt source 2400 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.172906] [fglrx:firegl_cmmqs_init] *ERROR* CMMQS init:GAL is not initialized. Jun 7 14:21:42 host kernel: [ 105.172909] [fglrx:firegl_cmmqs_createdriver] *ERROR* CMMQS Initialization failed: firegl_cmmqs_createdriver Jun 7 14:21:42 host kernel: [ 105.172940] [fglrx:firegl_cmmqs_BIOSControl] *ERROR* CMMQS BIOS Control: CMMQS handle is not valid. Jun 7 14:21:42 host kernel: [ 105.172942] [fglrx:firegl_bios_control] *ERROR* CMMQS BIOS Control is failed: firegl_bios_control Jun 7 14:21:42 host kernel: [ 105.195648] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0017 address=0x000f00268a00 flags=0x0010] Jun 7 14:21:42 host kernel: [ 105.195651] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0017
Re: [PATCH] PCI: Add Ralink RT2800 broken INTx masking quirk
On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. That's exactly what I meant. May I have please another question? Unfortunately I can't cleanly unmount filesystems during shutdown with your kernel (this problem doesn't happen with the patched 3.4 suse kernel). Hmm, are you using my kernel that's based on the next branch? Could be any number of things broken in next. I applied your vfio-patches from your git-repository to an openSUSE 3.4 kernel (plus one other to get the patches applied): iommu_core:_pass_a_user-provided_token_to_fault_handlers.patch 0ca4120cbaeaa2aecdccc5043b309fe1808aae2a.patch [PATCH] pci: Add PCI DMA source ID quirk db47c1f7313ad863818261f62f1babaf0b564e55.patch [PATCH] pci: Add ACS validation utility a89edb6943102d4519860bca5671740c1b7364cc.patch [PATCH] pci: export pci_user functions for use by other drivers 38fdda7327b6cf50c1265a6332e94b97100aa10e.patch [PATCH] pci: Create common pcibios_err_to_errno cb6e045625e5a217df3cebcb4585b40cbcad6c96.patch [PATCH] pci: Misc pci_reg additions c6985f9b501903f5c707a1711fa53dc94c72f999.patch [PATCH] driver core: Add iommu_group tracking to struct device 581187e853620c52e4b78db643161cc3be2f3388.patch [PATCH] iommu: IOMMU Groups 635e48574089f4c8205a2fd7b1d85edd02344fe5.patch [PATCH] amd_iommu: Support IOMMU groups 37f2d6d5217fdd2facd9641b83fde683263adcaf.patch [PATCH] intel-iommu: Support IOMMU groups 351d849a51787140736e04f261ae9db09c980868.patch [PATCH] amd_iommu: Make use of DMA quirks and ACS checks in IOMMU 92eef0a72193ef8504eea10b4ccbdb2e1ee9f4b3.patch [PATCH] intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups dd2886fe0a8936d649a365162658406e7a18d274.patch [PATCH] iommu: Remove group_mf 6891b9a7d56841e592cfb444a7f4b2b02831f866.patch [PATCH] vfio: VFIO core 51b06ff680d8bc30d1bd627e2dd24641789be55d.patch [PATCH] vfio: Add documentation 4b36b306122a225d33e947e7f9e6d1117a4fb699.patch [PATCH] vfio: Type1 IOMMU implementation 91e4950e482b142dd9ab46f0ec386c5eed9f1470.patch [PATCH] vfio: Add PCI device driver PCI:_Mark_INTx_masking_support_of_Chelsio_T310_10GbE_NIC_as_broken.patch PCI:_Add_Ralink_RT2800_broken_INTx_masking_quirk.patch IRQF_ONESHOT.patch The VM does work as expected, but fglrx isn't happy any more (but worked fine with your kernel and works fine, too, with the unpatched suse 3.4 kernel). fglrx says: So you're saying: kernel built from my tree: fglrx works opensuse kernel: fglrx works opensuse kernel + above patches: failure below? Jun 7 14:21:42 host kernel: [ 105.103610] [fglrx:firegl_cail_init] *ERROR* CAIL: CAILInitialize failed, error 1 Jun 7 14:21:42 host kernel: [ 105.103613] [fglrx:hal_init_asic] *ERROR* Failed to initialize ASIC. Jun 7 14:21:42 host kernel: [ 105.103645] [fglrx:firegl_init_pcie] *ERROR* Can not get FB size Jun 7 14:21:42 host kernel: [ 105.103653] [fglrx:IRQMGR_alloc_context] *ERROR* IRQMGR_GetExtensionSize returned 0 Jun 7 14:21:42 host kernel: [ 105.103654] [fglrx:irqmgr_wrap_initialize] *ERROR* Fail to allocate IRQMGR context! Jun 7 14:21:42 host kernel: [ 105.109151] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff32 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.109173] [fglrx:firegl_irq_enable] *ERROR* interrupt source 1000 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169073] [fglrx:firegl_irq_enable] *ERROR* interrupt source 6001 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169107] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff2c is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169125] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff4e is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169142] [fglrx:firegl_irq_enable] *ERROR* interrupt source 2400 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.172906] [fglrx:firegl_cmmqs_init] *ERROR* CMMQS init:GAL is not initialized. Jun 7 14:21:42 host kernel: [ 105.172909] [fglrx:firegl_cmmqs_createdriver] *ERROR* CMMQS Initialization failed: firegl_cmmqs_createdriver Jun 7 14:21:42 host kernel: [ 105.172940] [fglrx:firegl_cmmqs_BIOSControl] *ERROR* CMMQS BIOS Control: CMMQS handle is not valid. Jun 7
Re: [PATCH] PCI: Add Ralink RT2800 broken INTx masking quirk
Alex Williamson wrote: On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. That's exactly what I meant. May I have please another question? Unfortunately I can't cleanly unmount filesystems during shutdown with your kernel (this problem doesn't happen with the patched 3.4 suse kernel). Hmm, are you using my kernel that's based on the next branch? Could be any number of things broken in next. I applied your vfio-patches from your git-repository to an openSUSE 3.4 kernel (plus one other to get the patches applied): iommu_core:_pass_a_user-provided_token_to_fault_handlers.patch 0ca4120cbaeaa2aecdccc5043b309fe1808aae2a.patch [PATCH] pci: Add PCI DMA source ID quirk db47c1f7313ad863818261f62f1babaf0b564e55.patch [PATCH] pci: Add ACS validation utility a89edb6943102d4519860bca5671740c1b7364cc.patch [PATCH] pci: export pci_user functions for use by other drivers 38fdda7327b6cf50c1265a6332e94b97100aa10e.patch [PATCH] pci: Create common pcibios_err_to_errno cb6e045625e5a217df3cebcb4585b40cbcad6c96.patch [PATCH] pci: Misc pci_reg additions c6985f9b501903f5c707a1711fa53dc94c72f999.patch [PATCH] driver core: Add iommu_group tracking to struct device 581187e853620c52e4b78db643161cc3be2f3388.patch [PATCH] iommu: IOMMU Groups 635e48574089f4c8205a2fd7b1d85edd02344fe5.patch [PATCH] amd_iommu: Support IOMMU groups 37f2d6d5217fdd2facd9641b83fde683263adcaf.patch [PATCH] intel-iommu: Support IOMMU groups 351d849a51787140736e04f261ae9db09c980868.patch [PATCH] amd_iommu: Make use of DMA quirks and ACS checks in IOMMU 92eef0a72193ef8504eea10b4ccbdb2e1ee9f4b3.patch [PATCH] intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups dd2886fe0a8936d649a365162658406e7a18d274.patch [PATCH] iommu: Remove group_mf 6891b9a7d56841e592cfb444a7f4b2b02831f866.patch [PATCH] vfio: VFIO core 51b06ff680d8bc30d1bd627e2dd24641789be55d.patch [PATCH] vfio: Add documentation 4b36b306122a225d33e947e7f9e6d1117a4fb699.patch [PATCH] vfio: Type1 IOMMU implementation 91e4950e482b142dd9ab46f0ec386c5eed9f1470.patch [PATCH] vfio: Add PCI device driver PCI:_Mark_INTx_masking_support_of_Chelsio_T310_10GbE_NIC_as_broken.patch PCI:_Add_Ralink_RT2800_broken_INTx_masking_quirk.patch IRQF_ONESHOT.patch The VM does work as expected, but fglrx isn't happy any more (but worked fine with your kernel and works fine, too, with the unpatched suse 3.4 kernel). fglrx says: So you're saying: kernel built from my tree: fglrx works opensuse kernel: fglrx works opensuse kernel + above patches: failure below? Exactly. Jun 7 14:21:42 host kernel: [ 105.103610] [fglrx:firegl_cail_init] *ERROR* CAIL: CAILInitialize failed, error 1 Jun 7 14:21:42 host kernel: [ 105.103613] [fglrx:hal_init_asic] *ERROR* Failed to initialize ASIC. Jun 7 14:21:42 host kernel: [ 105.103645] [fglrx:firegl_init_pcie] *ERROR* Can not get FB size Jun 7 14:21:42 host kernel: [ 105.103653] [fglrx:IRQMGR_alloc_context] *ERROR* IRQMGR_GetExtensionSize returned 0 Jun 7 14:21:42 host kernel: [ 105.103654] [fglrx:irqmgr_wrap_initialize] *ERROR* Fail to allocate IRQMGR context! Jun 7 14:21:42 host kernel: [ 105.109151] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff32 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.109173] [fglrx:firegl_irq_enable] *ERROR* interrupt source 1000 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169073] [fglrx:firegl_irq_enable] *ERROR* interrupt source 6001 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169107] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff2c is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169125] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff4e is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169142] [fglrx:firegl_irq_enable] *ERROR* interrupt source 2400 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.172906] [fglrx:firegl_cmmqs_init] *ERROR* CMMQS init:GAL is not initialized. Jun 7 14:21:42 host kernel: [ 105.172909] [fglrx:firegl_cmmqs_createdriver] *ERROR* CMMQS Initialization failed: firegl_cmmqs_createdriver Jun 7 14:21:42 host kernel: [ 105.172940] [fglrx:firegl_cmmqs_BIOSControl] *ERROR* CMMQS BIOS
Re: [PATCH] PCI: Add Ralink RT2800 broken INTx masking quirk
On Thu, 2012-06-07 at 23:42 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Thu, 2012-06-07 at 08:18 +0200, Andreas Hartmann wrote: Hello Alex, what about a module parameter to achieve this behaviour manually by the user without recompiling? I fear, there are much more candidates out there needing this feature. Yeah, that's probably a good idea. For debugging and letting users have a workaround rather than any kind of regular use. I'll add a nointxmask to vfio-pci with a description indicating that if it fixes a device to report it for quirking. That's exactly what I meant. May I have please another question? Unfortunately I can't cleanly unmount filesystems during shutdown with your kernel (this problem doesn't happen with the patched 3.4 suse kernel). Hmm, are you using my kernel that's based on the next branch? Could be any number of things broken in next. I applied your vfio-patches from your git-repository to an openSUSE 3.4 kernel (plus one other to get the patches applied): iommu_core:_pass_a_user-provided_token_to_fault_handlers.patch 0ca4120cbaeaa2aecdccc5043b309fe1808aae2a.patch [PATCH] pci: Add PCI DMA source ID quirk db47c1f7313ad863818261f62f1babaf0b564e55.patch [PATCH] pci: Add ACS validation utility a89edb6943102d4519860bca5671740c1b7364cc.patch [PATCH] pci: export pci_user functions for use by other drivers 38fdda7327b6cf50c1265a6332e94b97100aa10e.patch [PATCH] pci: Create common pcibios_err_to_errno cb6e045625e5a217df3cebcb4585b40cbcad6c96.patch [PATCH] pci: Misc pci_reg additions c6985f9b501903f5c707a1711fa53dc94c72f999.patch [PATCH] driver core: Add iommu_group tracking to struct device 581187e853620c52e4b78db643161cc3be2f3388.patch [PATCH] iommu: IOMMU Groups 635e48574089f4c8205a2fd7b1d85edd02344fe5.patch [PATCH] amd_iommu: Support IOMMU groups 37f2d6d5217fdd2facd9641b83fde683263adcaf.patch [PATCH] intel-iommu: Support IOMMU groups 351d849a51787140736e04f261ae9db09c980868.patch [PATCH] amd_iommu: Make use of DMA quirks and ACS checks in IOMMU 92eef0a72193ef8504eea10b4ccbdb2e1ee9f4b3.patch [PATCH] intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups dd2886fe0a8936d649a365162658406e7a18d274.patch [PATCH] iommu: Remove group_mf 6891b9a7d56841e592cfb444a7f4b2b02831f866.patch [PATCH] vfio: VFIO core 51b06ff680d8bc30d1bd627e2dd24641789be55d.patch [PATCH] vfio: Add documentation 4b36b306122a225d33e947e7f9e6d1117a4fb699.patch [PATCH] vfio: Type1 IOMMU implementation 91e4950e482b142dd9ab46f0ec386c5eed9f1470.patch [PATCH] vfio: Add PCI device driver PCI:_Mark_INTx_masking_support_of_Chelsio_T310_10GbE_NIC_as_broken.patch PCI:_Add_Ralink_RT2800_broken_INTx_masking_quirk.patch IRQF_ONESHOT.patch The VM does work as expected, but fglrx isn't happy any more (but worked fine with your kernel and works fine, too, with the unpatched suse 3.4 kernel). fglrx says: So you're saying: kernel built from my tree: fglrx works opensuse kernel: fglrx works opensuse kernel + above patches: failure below? Exactly. Jun 7 14:21:42 host kernel: [ 105.103610] [fglrx:firegl_cail_init] *ERROR* CAIL: CAILInitialize failed, error 1 Jun 7 14:21:42 host kernel: [ 105.103613] [fglrx:hal_init_asic] *ERROR* Failed to initialize ASIC. Jun 7 14:21:42 host kernel: [ 105.103645] [fglrx:firegl_init_pcie] *ERROR* Can not get FB size Jun 7 14:21:42 host kernel: [ 105.103653] [fglrx:IRQMGR_alloc_context] *ERROR* IRQMGR_GetExtensionSize returned 0 Jun 7 14:21:42 host kernel: [ 105.103654] [fglrx:irqmgr_wrap_initialize] *ERROR* Fail to allocate IRQMGR context! Jun 7 14:21:42 host kernel: [ 105.109151] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff32 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.109173] [fglrx:firegl_irq_enable] *ERROR* interrupt source 1000 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169073] [fglrx:firegl_irq_enable] *ERROR* interrupt source 6001 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169107] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff2c is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169125] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff4e is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169142] [fglrx:firegl_irq_enable] *ERROR* interrupt source 2400 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.172906] [fglrx:firegl_cmmqs_init] *ERROR* CMMQS init:GAL is not initialized. Jun 7 14:21:42 host kernel: [ 105.172909]
Re: [PATCH] PCI: Add Ralink RT2800 broken INTx masking quirk
Alex Williamson wrote: On Thu, 2012-06-07 at 23:42 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Thu, 2012-06-07 at 23:01 +0200, Andreas Hartmann wrote: [...] May I have please another question? Unfortunately I can't cleanly unmount filesystems during shutdown with your kernel (this problem doesn't happen with the patched 3.4 suse kernel). Hmm, are you using my kernel that's based on the next branch? Could be any number of things broken in next. I applied your vfio-patches from your git-repository to an openSUSE 3.4 kernel (plus one other to get the patches applied): iommu_core:_pass_a_user-provided_token_to_fault_handlers.patch 0ca4120cbaeaa2aecdccc5043b309fe1808aae2a.patch [PATCH] pci: Add PCI DMA source ID quirk db47c1f7313ad863818261f62f1babaf0b564e55.patch [PATCH] pci: Add ACS validation utility a89edb6943102d4519860bca5671740c1b7364cc.patch [PATCH] pci: export pci_user functions for use by other drivers 38fdda7327b6cf50c1265a6332e94b97100aa10e.patch [PATCH] pci: Create common pcibios_err_to_errno cb6e045625e5a217df3cebcb4585b40cbcad6c96.patch [PATCH] pci: Misc pci_reg additions c6985f9b501903f5c707a1711fa53dc94c72f999.patch [PATCH] driver core: Add iommu_group tracking to struct device 581187e853620c52e4b78db643161cc3be2f3388.patch [PATCH] iommu: IOMMU Groups 635e48574089f4c8205a2fd7b1d85edd02344fe5.patch [PATCH] amd_iommu: Support IOMMU groups 37f2d6d5217fdd2facd9641b83fde683263adcaf.patch [PATCH] intel-iommu: Support IOMMU groups 351d849a51787140736e04f261ae9db09c980868.patch [PATCH] amd_iommu: Make use of DMA quirks and ACS checks in IOMMU 92eef0a72193ef8504eea10b4ccbdb2e1ee9f4b3.patch [PATCH] intel-iommu: Make use of DMA quirks and ACS checks in IOMMU groups dd2886fe0a8936d649a365162658406e7a18d274.patch [PATCH] iommu: Remove group_mf 6891b9a7d56841e592cfb444a7f4b2b02831f866.patch [PATCH] vfio: VFIO core 51b06ff680d8bc30d1bd627e2dd24641789be55d.patch [PATCH] vfio: Add documentation 4b36b306122a225d33e947e7f9e6d1117a4fb699.patch [PATCH] vfio: Type1 IOMMU implementation 91e4950e482b142dd9ab46f0ec386c5eed9f1470.patch [PATCH] vfio: Add PCI device driver PCI:_Mark_INTx_masking_support_of_Chelsio_T310_10GbE_NIC_as_broken.patch PCI:_Add_Ralink_RT2800_broken_INTx_masking_quirk.patch IRQF_ONESHOT.patch The VM does work as expected, but fglrx isn't happy any more (but worked fine with your kernel and works fine, too, with the unpatched suse 3.4 kernel). fglrx says: So you're saying: kernel built from my tree: fglrx works opensuse kernel: fglrx works opensuse kernel + above patches: failure below? Until now, I wasn't able to get the opensuse 4.1 kernel running. Exactly. Jun 7 14:21:42 host kernel: [ 105.103610] [fglrx:firegl_cail_init] *ERROR* CAIL: CAILInitialize failed, error 1 Jun 7 14:21:42 host kernel: [ 105.103613] [fglrx:hal_init_asic] *ERROR* Failed to initialize ASIC. Jun 7 14:21:42 host kernel: [ 105.103645] [fglrx:firegl_init_pcie] *ERROR* Can not get FB size Jun 7 14:21:42 host kernel: [ 105.103653] [fglrx:IRQMGR_alloc_context] *ERROR* IRQMGR_GetExtensionSize returned 0 Jun 7 14:21:42 host kernel: [ 105.103654] [fglrx:irqmgr_wrap_initialize] *ERROR* Fail to allocate IRQMGR context! Jun 7 14:21:42 host kernel: [ 105.109151] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff32 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.109173] [fglrx:firegl_irq_enable] *ERROR* interrupt source 1000 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169073] [fglrx:firegl_irq_enable] *ERROR* interrupt source 6001 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169107] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff2c is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169125] [fglrx:firegl_irq_enable] *ERROR* interrupt source ff4e is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.169142] [fglrx:firegl_irq_enable] *ERROR* interrupt source 2400 is not supported on this hardware (return code = 2) Jun 7 14:21:42 host kernel: [ 105.172906] [fglrx:firegl_cmmqs_init] *ERROR* CMMQS init:GAL is not initialized. Jun 7 14:21:42 host kernel: [ 105.172909] [fglrx:firegl_cmmqs_createdriver] *ERROR* CMMQS Initialization failed: firegl_cmmqs_createdriver Jun 7 14:21:42 host kernel: [ 105.172940] [fglrx:firegl_cmmqs_BIOSControl] *ERROR* CMMQS BIOS Control: CMMQS handle is not valid. Jun 7 14:21:42 host kernel: [ 105.172942] [fglrx:firegl_bios_control] *ERROR* CMMQS BIOS Control is failed: firegl_bios_control Jun 7 14:21:42 host kernel: [ 105.195648] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0017 address=0x000f00268a00 flags=0x0010] Jun 7 14:21:42 host kernel: [ 105.195651] AMD-Vi: Event logged
Re: [PATCH] kvm tools: Process virito blk requests in separate thread
On Thu, Jun 7, 2012 at 4:47 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 07/06/2012 03:38, Asias He ha scritto:
I never looked at the kvmtool code, but I think Asias has a point. If
the guest submits I/O to lots of devices, they would contend on the
single thread. There was a similar proof of concept patch for QEMU that
provided substantial benefit.
However, it sounds a bit wasteful to have the dedicated thread run with
a second eventfd. Would it be hard to just use the virtio-blk ioeventfd
directly?
Without this patch, we are already using the virtio-blk ioeventfd
which is being monitored in the shared ioeventfd__thread() thead.
Yes, I understood that. :)
;-)
I'm wondering why it is still necessary to
monitor that eventfd in the shared thread. Perhaps you could optionally
skip the epoll registration/deregistration in ioeventfd__{add,del}_event.
Yes, we can monitor the eventfd only in block thread. But that
requires changing our virtio core code and doing ioeventfd setup in
block specific code. This still does not save a thread for us. And the
overhead of using shared eventfd + notify to block thead should be
small. So I'd prefer the current model.
--
Asias He
--
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
[Bug 43355] New: kvm error and make network slow
https://bugzilla.kernel.org/show_bug.cgi?id=43355 Summary: kvm error and make network slow Product: Virtualization Version: unspecified Kernel Version: 2.6.32 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: zhuxueg...@360buy.com Regression: No I user kvm and make network bridge.use iperf to test network. E:\xuegang\tools\iperfcall iperf.exe -d -c 10.28.168.207 -p 3377 -i 1 -t 600 WARNING: option -d is not valid for server mode Client connecting to 10.28.168.207, TCP port 3377 TCP window size: 8.00 KByte (default) [220] local 10.28.168.44 port 51751 connected with 10.28.168.207 port 3377 [ ID] Interval Transfer Bandwidth [220] 0.0- 1.0 sec 34.9 MBytes 293 Mbits/sec [220] 1.0- 2.0 sec 34.3 MBytes 288 Mbits/sec [220] 0.0- 3.0 sec 113 MBytes 319 Mbits/sec E:\xuegang\tools\iperfcall iperf.exe -d -c 10.28.168.207 -p 3377 -i 1 -t 600 WARNING: option -d is not valid for server mode Client connecting to 10.28.168.207, TCP port 3377 TCP window size: 8.00 KByte (default) [220] local 10.28.168.44 port 55627 connected with 10.28.168.207 port 3377 [ ID] Interval Transfer Bandwidth [220] 0.0- 1.0 sec 136 KBytes 1.11 Mbits/sec [220] 1.0- 2.0 sec 160 KBytes 1.31 Mbits/sec [220] 2.0- 3.0 sec 160 KBytes 1.31 Mbits/sec [220] 0.0- 3.6 sec 528 KBytes 1.20 Mbits/sec E:\xuegang\tools\iperf kvm error: [root@kvm test_2]# Message from syslogd@kvm at Jun 8 11:43:00 ... kernel:Disabling IRQ #19 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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: Virtual machine does not respond to keyboard input when guest OS idles for a while
On 2012-06-07 03:26, Fei K Chen wrote: hi everyone, This is Fei Chen from IBM Research China. I and my team are working on enabling qemu-kvm on IBM prism A2 processor. Just a note: Don't use qemu-kvm as basis, use upstream QEMU or qemu-kvm's uq/master branch (if you have generic kvm subsystem changes). qemu-kvm is an x86-only fork that is fading out. Jan signature.asc Description: OpenPGP digital signature
