Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 10.11.2017 17:29, Paolo Bonzini wrote: On 10/11/2017 16:33, Gerhard Wiesinger wrote: Hello Paolo, Any update for a new patch? Yes, https://marc.info/?l=kvm&m=150997149623548&w=2 Paolo Works also for Fedora 26: https://koji.fedoraproject.org/koji/buildinfo?buildID=996781 kernel-4.13.12-200.fc26 Ready to release to 4.13.* upstream and 4.14 upstream kernels ... https://bodhi.fedoraproject.org/updates/FEDORA-2017-abda708cee Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 10.10.2017 16:16, Paolo Bonzini wrote:
On 27/09/2017 21:31, Gerhard Wiesinger wrote:
On 15.09.2017 19:07, Paolo Bonzini wrote:
On 15/09/2017 16:43, Gerhard Wiesinger wrote:
On 27.08.2017 20:55, Paolo Bonzini wrote:
Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" mailto:li...@wiesinger.com>> ha scritto:
On 27.08.2017 14 :03, Paolo Bonzini wrote:
We will revert the patch, but 4.13.0 will not have the fix.
Expect it in later stable kernels (because vacations).
Thnx. Why will 4.13.0 NOT have the fix?
Because maintainers are on vacation! :-)
Hello Paolo,
Any update on this for 4.12 and 4.13 kernels?
A late fix is better than a wrong fix. Hope to get to it next week!
Hello Paolo,
Any update? Thnx.
Hey, I have a patch now. Any volunteers for testing it?
This is on top of 4.13.
Paolo
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6ef2940119b..c29bf36485fd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -200,6 +200,10 @@ struct loaded_vmcs {
int cpu;
bool launched;
bool nmi_known_unmasked;
+ /* Support for vnmi-less CPUs */
+ int soft_vnmi_blocked;
+ ktime_t entry_time;
+ s64 vnmi_blocked_time;
struct list_head loaded_vmcss_on_cpu_link;
};
Hello Paolo,
The patch does not apply, 1st hunk FAILED.
cat arch/x86/kvm/vmx.c.rej
--- arch/x86/kvm/vmx.c
+++ arch/x86/kvm/vmx.c
@@ -200,6 +200,10 @@ struct loaded_vmcs {
int cpu;
bool launched;
bool nmi_known_unmasked;
+ /* Support for vnmi-less CPUs */
+ int soft_vnmi_blocked;
+ ktime_t entry_time;
+ s64 vnmi_blocked_time;
struct list_head loaded_vmcss_on_cpu_link;
};
Tried it to apply against, doesn't look to fit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/kvm/vmx.c?h=v4.13.10#n197
https://koji.fedoraproject.org/koji/buildinfo?buildID=991441
Will then recompile and test.
Thnx.
Ciao,
Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 15.09.2017 19:07, Paolo Bonzini wrote: On 15/09/2017 16:43, Gerhard Wiesinger wrote: On 27.08.2017 20:55, Paolo Bonzini wrote: Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" mailto:li...@wiesinger.com>> ha scritto: On 27.08.2017 14 :03, Paolo Bonzini wrote: We will revert the patch, but 4.13.0 will not have the fix. Expect it in later stable kernels (because vacations). Thnx. Why will 4.13.0 NOT have the fix? Because maintainers are on vacation! :-) Hello Paolo, Any update on this for 4.12 and 4.13 kernels? A late fix is better than a wrong fix. Hope to get to it next week! Hello Paolo, Any update? Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 27.08.2017 20:55, Paolo Bonzini wrote: Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" <mailto:li...@wiesinger.com>> ha scritto: On 27.08.2017 14 :03, Paolo Bonzini wrote: We will revert the patch, but 4.13.0 will not have the fix. Expect it in later stable kernels (because vacations). Thnx. Why will 4.13.0 NOT have the fix? Because maintainers are on vacation! :-) Hello Paolo, Any update on this for 4.12 and 4.13 kernels? Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 27.08.2017 14:03, Paolo Bonzini wrote: Il 27 ago 2017 9:49 AM, "Gerhard Wiesinger" ha scritto: On 17.08.2017 23:14, Gerhard Wiesinger wrote: On 17.08.2017 22:58, Gerhard Wiesinger wrote: On 07.08.2017 19:50, Paolo Bonzini wrote: Not much to say, unfortunately. It's pretty much the same capabilities as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It also lacks FlexPriority compared to the Conroe I had checked. It's not great that even the revert patch doesn't apply cleanly---this is *not* necessarily a boring area of the hypervisor... Given the rarity of your machine I'm currently leaning towards _not_ reverting the change. I'll check another non-Xeon Core 2 tomorrow that is from December 2008 (IIRC). If that one also lacks vNMI, or if I get other reports, I suppose I will have to reconsider that. Hello Paolo, Can you please revert the patch. CPU is a Core 2 Extreme QX6700: SL9UL (B3) running VERY stable with ECC RAM for years now. https://ark.intel.com/products/28028/Intel-Core2-Extreme- Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core% 202%20Extreme%20QX6700 https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors CPU details below. Thank you. Ciao, Gerhard Hello Paolo, Any update on this major issue? We will revert the patch, but 4.13.0 will not have the fix. Expect it in later stable kernels (because vacations). Thnx. Why will 4.13.0 NOT have the fix? Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 27.08.2017 14:03, Paolo Bonzini wrote: Il 27 ago 2017 9:49 AM, "Gerhard Wiesinger" <mailto:li...@wiesinger.com>> ha scritto: On 17.08.2017 23:14, Gerhard Wiesinger wrote: On 17.08.2017 22:58, Gerhard Wiesinger wrote: > > On 07.08.2017 19:50, Paolo Bonzini wrote: > > >Not much to say, unfortunately. It's pretty much the same capabilities > >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It > >also lacks FlexPriority compared to the Conroe I had checked. > > > >It's not great that even the revert patch doesn't apply cleanly---this > >is *not* necessarily a boring area of the hypervisor... > > > >Given the rarity of your machine I'm currently leaning towards _not_ > >reverting the change. I'll check another non-Xeon Core 2 tomorrow that > >is from December 2008 (IIRC). If that one also lacks vNMI, or if I get > >other reports, I suppose I will have to reconsider that. Hello Paolo, Can you please revert the patch. CPU is a Core 2 Extreme QX6700: SL9UL (B3) running VERY stable with ECC RAM for years now. https://ark.intel.com/products/28028/Intel-Core2-Extreme-Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core%202%20Extreme%20QX6700 <https://ark.intel.com/products/28028/Intel-Core2-Extreme-Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core%202%20Extreme%20QX6700> https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors <https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors> CPU details below. Thank you. Ciao, Gerhard Hello Paolo, Any update on this major issue? We will revert the patch, but 4.13.0 will not have the fix. Expect it in later stable kernels (because vacations). Thnx. Why will 4.13.0 NOT have the fix? Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 17.08.2017 23:14, Gerhard Wiesinger wrote: On 17.08.2017 22:58, Gerhard Wiesinger wrote: > > On 07.08.2017 19:50, Paolo Bonzini wrote: > > >Not much to say, unfortunately. It's pretty much the same capabilities > >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It > >also lacks FlexPriority compared to the Conroe I had checked. > > > >It's not great that even the revert patch doesn't apply cleanly---this > >is *not* necessarily a boring area of the hypervisor... > > > >Given the rarity of your machine I'm currently leaning towards _not_ > >reverting the change. I'll check another non-Xeon Core 2 tomorrow that > >is from December 2008 (IIRC). If that one also lacks vNMI, or if I get > >other reports, I suppose I will have to reconsider that. Hello Paolo, Can you please revert the patch. CPU is a Core 2 Extreme QX6700: SL9UL (B3) running VERY stable with ECC RAM for years now. https://ark.intel.com/products/28028/Intel-Core2-Extreme-Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core%202%20Extreme%20QX6700 https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors CPU details below. Thank you. Ciao, Gerhard Hello Paolo, Any update on this major issue? Thnx. Ciao, Gerhard
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 07.08.2017 19:50, Paolo Bonzini wrote: >Not much to say, unfortunately. It's pretty much the same capabilities >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It >also lacks FlexPriority compared to the Conroe I had checked. > >It's not great that even the revert patch doesn't apply cleanly---this >is *not* necessarily a boring area of the hypervisor... > >Given the rarity of your machine I'm currently leaning towards _not_ >reverting the change. I'll check another non-Xeon Core 2 tomorrow that >is from December 2008 (IIRC). If that one also lacks vNMI, or if I get >other reports, I suppose I will have to reconsider that. Hello Paolo, Can you please revert the patch. CPU is a Core 2 Extreme QX6700: SL9UL (B3) running VERY stable with ECC RAM for years now. https://ark.intel.com/products/28028/Intel-Core2-Extreme-Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core%202%20Extreme%20QX6700 https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors CPU details below. Thank you. Ciao, Gerhard cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz stepping : 7 microcode : 0x6a cpu MHz : 1596.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 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 lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 5333.45 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Script output: Basic VMX Information Hex: 0x1a0407 Revision 7 VMCS size 1024 VMCS restricted to 32 bit addresses no Dual-monitor support yes VMCS memory type 6 INS/OUTS instruction information no IA32_VMX_TRUE_*_CTLS support no pin-based controls External interrupt exiting yes NMI exiting yes Virtual NMIs no Activate VMX-preemption timer no Process posted interrupts no primary processor-based controls Interrupt window exiting yes Use TSC offsetting yes HLT exiting yes INVLPG exiting yes MWAIT exiting yes RDPMC exiting yes RDTSC exiting yes CR3-load exiting forced CR3-store exiting forced CR8-load exiting yes CR8-store exiting yes Use TPR shadow yes NMI-window exiting no MOV-DR exiting yes Unconditional I/O exiting yes Use I/O bitmaps yes Monitor trap flag no Use MSR bitmaps yes MONITOR exiting yes PAUSE exiting yes Activate secondary control no secondary processor-based controls Virtualize APIC accesses no Enable EPT no Descriptor-table exiting no Enable RDTSCP no Virtualize x2APIC mode no Enable VPID no WBINVD exiting no Unrestricted guest no APIC register emulation no Virtual interrupt delivery no PAUSE-loop exiting no RDRAND exiting no Enable INVPCID no Enable VM functions no VMCS shadowing no Enable ENCLS exiting no RDSEED exiting no Enable PML no EPT-violation #VE no Conceal non-root operation from PT no Enable XSAVES/XRSTORS no Mode-based execute control (XS/XU) no TSC scaling no VM-Exit controls Save debug controls forced Host address-space size yes Load IA32_PERF_GLOBAL_CTRL no Acknowledge interrupt on exit yes Save IA32_PAT no L
Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12
On 17.08.2017 22:58, Gerhard Wiesinger wrote: > > On 07.08.2017 19:50, Paolo Bonzini wrote: > > >Not much to say, unfortunately. It's pretty much the same capabilities > >as a Prescott/Cedar Mill processor, except that it has MSR bitmaps. It > >also lacks FlexPriority compared to the Conroe I had checked. > > > >It's not great that even the revert patch doesn't apply cleanly---this > >is *not* necessarily a boring area of the hypervisor... > > > >Given the rarity of your machine I'm currently leaning towards _not_ > >reverting the change. I'll check another non-Xeon Core 2 tomorrow that > >is from December 2008 (IIRC). If that one also lacks vNMI, or if I get > >other reports, I suppose I will have to reconsider that. Hello Paolo, Can you please revert the patch. CPU is a Core 2 Extreme QX6700: SL9UL (B3) running VERY stable with ECC RAM for years now. https://ark.intel.com/products/28028/Intel-Core2-Extreme-Processor-QX6700-8M-Cache-2_66-GHz-1066-MHz-FSB?q=Core%202%20Extreme%20QX6700 https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors CPU details below. Thank you. Ciao, Gerhard cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz stepping : 7 microcode : 0x6a cpu MHz : 1596.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 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 lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 5333.45 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Script output: Basic VMX Information Hex: 0x1a0407 Revision 7 VMCS size 1024 VMCS restricted to 32 bit addresses no Dual-monitor support yes VMCS memory type 6 INS/OUTS instruction information no IA32_VMX_TRUE_*_CTLS support no pin-based controls External interrupt exiting yes NMI exiting yes Virtual NMIs no Activate VMX-preemption timer no Process posted interrupts no primary processor-based controls Interrupt window exiting yes Use TSC offsetting yes HLT exiting yes INVLPG exiting yes MWAIT exiting yes RDPMC exiting yes RDTSC exiting yes CR3-load exiting forced CR3-store exiting forced CR8-load exiting yes CR8-store exiting yes Use TPR shadow yes NMI-window exiting no MOV-DR exiting yes Unconditional I/O exiting yes Use I/O bitmaps yes Monitor trap flag no Use MSR bitmaps yes MONITOR exiting yes PAUSE exiting yes Activate secondary control no secondary processor-based controls Virtualize APIC accesses no Enable EPT no Descriptor-table exiting no Enable RDTSCP no Virtualize x2APIC mode no Enable VPID no WBINVD exiting no Unrestricted guest no APIC register emulation no Virtual interrupt delivery no PAUSE-loop exiting no RDRAND exiting no Enable INVPCID no Enable VM functions no VMCS shadowing no Enable ENCLS exiting no RDSEED exiting no Enable PML no EPT-violation #VE no Conceal non-root operation from PT no Enable XSAVES/XRSTORS no Mode-based execute control (XS/XU) no TSC scaling no VM-Exit controls Save debug controls forced Host address-s
[Qemu-devel] [PATCH] Add DOS support for RTL8139
Signed-off-by: Gerhard Wiesinger
---
hw/net/rtl8139.c | 288
++-
1 file changed, 264 insertions(+), 24 deletions(-)
diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index f05e59c..5241fea 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -48,6 +48,17 @@
* 2011-Mar-22 Benjamin Poirier: Implemented VLAN offloading
*/
+/*
+ * Testcases and successful regression tests:
+ * 1.) DOS RSET8139.EXE: EEPROM Test successful
+ * 2.) DOS RSET8139.EXE: Local loopback Test (Run Diagnostics On Board)
+ * 3.) DOS RSET8139.EXE: Remote loopback Test as Initiator (Run
Diagnostics On Network)
+ * 4.) DOS RSET8139.EXE: Remote loopback Test as Responder (Run
Diagnostics On Network)
+ * 5.) DOS driver: Loads and works
+ * 6.) Linux tests
+ * 7.) Windows tests
+ */
+
/* For crc32 */
#include "qemu/osdep.h"
#include
@@ -130,6 +141,7 @@ enum RTL8139_registers {
NWayExpansion = 0x6A,
/* Undocumented registers, but required for proper operation. */
FIFOTMS = 0x70,/* FIFO Control and test. */
+RX_ER = 0x72, /* RX_ER Counter */
CSCR = 0x74,/* Chip Status and Configuration Register. */
PARA78 = 0x78,
PARA7c = 0x7c,/* Magic transceiver parameter register. */
@@ -472,6 +484,8 @@ typedef struct RTL8139State {
uint16_t NWayLPAR;
uint16_t NWayExpansion;
+uint16_t Fifo_TMS;
+
uint16_t CpCmd;
uint8_t TxThresh;
@@ -757,15 +771,27 @@ static void rtl8139_write_buffer(RTL8139State
*s, const void *buf, int size)
if (size > wrapped)
{
+DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x,
RxBuf+RxBufAddr=0x%x, "
+"buf=%p, size=%i, wrapped=%i, size-wrapped=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size, wrapped, size - wrapped
+ );
pci_dma_write(d, s->RxBuf + s->RxBufAddr,
- buf, size-wrapped);
+ buf, size - wrapped);
}
/* reset buffer pointer */
s->RxBufAddr = 0;
+DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x, RxBuf+RxBufAddr=0x%x, "
+"buf=%p, size=%i, wrapped=%i, size-wrapped=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size, wrapped, size - wrapped
+ );
pci_dma_write(d, s->RxBuf + s->RxBufAddr,
- buf + (size-wrapped), wrapped);
+ buf + (size - wrapped), wrapped);
s->RxBufAddr = wrapped;
@@ -774,6 +800,13 @@ static void rtl8139_write_buffer(RTL8139State *s,
const void *buf, int size)
}
/* non-wrapping path or overwrapping enabled */
+DPRINTF(">>> rx packet pci dma write "
+"RxBuf=0x%x, RxBufAddr=0x%x, RxBuf+RxBufAddr=0x%x, "
+"buf=%p, size=%i\n",
+s->RxBuf, s->RxBufAddr, s->RxBuf + s->RxBufAddr,
+buf, size
+ );
+
pci_dma_write(d, s->RxBuf + s->RxBufAddr, buf, size);
s->RxBufAddr += size;
@@ -1201,15 +1234,18 @@ static ssize_t rtl8139_receive(NetClientState
*nc, const uint8_t *buf, size_t si
static void rtl8139_reset_rxring(RTL8139State *s, uint32_t bufferSize)
{
s->RxBufferSize = bufferSize;
+/* Why not 0xFFF0? */
s->RxBufPtr = 0;
s->RxBufAddr = 0;
}
-static void rtl8139_reset(DeviceState *d)
+static void rtl8139_reset_delegate(DeviceState *d, int hard_reset)
{
RTL8139State *s = RTL8139(d);
int i;
+DPRINTF("rtl8139_reset_delegate, hard_reset=%i\n", hard_reset);
+
/* restore MAC address */
memcpy(s->phys, s->conf.macaddr.a, 6);
qemu_format_nic_info_str(qemu_get_queue(s->nic), s->phys);
@@ -1233,7 +1269,19 @@ static void rtl8139_reset(DeviceState *d)
s->RxRingAddrLO = 0;
s->RxRingAddrHI = 0;
-s->RxBuf = 0;
+/*
+ * DOS driver sets the RxBuf and then resets again.
+ * Afterwards RxBuf is not set anymore. Looks like real hardware
+ * also doesn't reset RxBuf on reset.
+ * When set to 0 DOS OS crashed because of adress 0 is overwritten ...
+ *
+ * On the other hand this must be done on a hardware triggered
+ * reset (a DMA enabled receiver might overwrite some areas!).
+ */
+
+if (hard_reset) {
+s->RxBuf = 0;
+}
rtl8139_reset_rxring(s, 8192);
@@ -1264,7 +1312,8 @@ static void rtl8139_reset(DeviceState *d)
//s->BasicModeCtrl = 0x3100; // 100Mbps, full duplex, autonegotiation
//s->Ba
[Qemu-devel] VNC - broken initial resolution
Hello, Since the last update (git log 3b71ec8..c5d128f) it looks like that the inital resolution via VNC is broken. E.g. after connecting seabios screen is not the typical text resolution but a lot larger than it should be. Any ideas? Anyone can reproduce it? Thnx. Ciao, Gerhard -- https://www.wiesinger.com/
Re: [Qemu-devel] QEMU/KVM performance gets worser - high load - high interrupts - high context switches
On 11.01.2016 09:22, Paolo Bonzini wrote: On 09/01/2016 17:46, Gerhard Wiesinger wrote: # Positive consequences via munin monitoring: # Reduced fork rate: 40 => 13 # process states: running 15 => <1 # CÜU temperature: (core dependant) 65-70°C => 56-64°C # CPU usage: system: 47% => 15%, user: 76% => 50% # Context Switches: 20k => 7.5k # Interrupts: 16k => 9k # Load average: 2.8 => 1 => back at the level before one year!!! Any idea why the serial device/PCI controller and the USB mouse tablet consume so much CPU on latest kernel and/or qemu? For USB, it's possible that you're not using the USB autosuspend feature? (As explained in Gerd's blog post, for Microsoft OSes you may need to fiddle with the registry). For virtio-serial, I have no idea. Linux VMs: All VMs are Linux VM on this KVM host, so as per blog post udev rules should apply well for USB autosuspend. Most of the effect came from the virtio-serial and not from USB tablet. For another KVM host with a Windows 7 VM: I tried to find apply the blog post: But there is no option "Allow the computer to turn off the device to save power" Nevertheless CPU usage could be reduced by removing the USB tablet from the Win7 VM. Ciao, Gerhard
Re: [Qemu-devel] QEMU/KVM performance gets worser - high load - high interrupts - high context switches
3On 08.12.2015 10:39, Gerhard Wiesinger wrote: Hello, Yesterday I looked at my munin statistics on my KVM host and I swar that performance gets worser: load is getting higher, interrupts are getting higher and are high as well as context switches. VMs and applications didn't change that way. You can find graphics at: http://www.wiesinger.com/tmp/kvm/ Last spike I guess was upgrade from FC22 to FC23 or a kernel update. And it was even lower on older versions For me it looks like the high interrupt load and context switches are the root cause. Interrupts inside the VM are <100, so with 10 VMs I'm expecting 1000+baseload => <2000, see statistics below. All VMs are virtio on disk/network except one (IDE/rtl8139). # Host as well as all guests (except 2 VMs): uname -a Linux kvm 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux qemu-system-x86-2.4.1-1.fc23.x86_64 Platform: All VMs have the pc-i440fx-2.4 profile (I upgraded yesterday from pc-i440fx-2.3 without any change). Any ideas, anyone having same issues? Ciao, Gerhard kvm: no VM running r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 0 3308516 102408 379856800 012 197 679 0 0 99 0 0 0 0 0 3308516 102416 379856400 042 197 914 0 0 99 1 0 0 0 0 3308516 102416 379856800 0 0 190 791 0 0 100 0 0 2 0 0 3308484 102416 379856800 0 0 129 440 0 0 100 0 0 kvm: 2 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 2641464 103052 381470000 0 0 2715 5648 3 2 95 0 0 0 0 0 2641340 103052 381470000 0 0 2601 1 2 97 0 0 1 0 0 2641308 103052 381470000 0 5 2687 5708 3 2 95 0 0 0 0 0 2640620 103060 381462800 030 2779 5756 4 3 93 1 0 0 0 0 2640644 103060 381463600 0 0 2436 5364 1 2 97 0 0 1 0 0 2640520 103060 381463600 0 119 2734 5975 3 2 95 0 0 kvm: all 10 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 60408 78892 337198400 085 9015 17357 4 9 87 0 0 2 0 0 60408 78892 337196800 047 9375 17797 9 9 82 0 0 0 0 0 60472 78892 3372092004060 8882 17343 4 8 86 1 0 1 0 0 60316 78892 337208000 059 8863 17517 4 8 87 0 0 0 0 0 59540 78900 337209200 055 9135 17796 8 9 81 1 0 0 0 0 59168 78900 337211200 051 8931 17484 4 9 87 0 0 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz stepping: 7 OK, I found what the problem is: analysis via: 1.) kvm_stat 2.) /usr/bin/perf record -p /usr/bin/perf report -i perf.data > perf-report.txt cat perf-report.txt # Overhead Command Shared ObjectSymbol # ... ... .. # 15.75% qemu-system-x86 [kernel.kallsyms][k] __fget 8.33% qemu-system-x86 [kernel.kallsyms][k] _raw_spin_lock_irqsave 7.54% qemu-system-x86 [kernel.kallsyms][k] fput 6.61% qemu-system-x86 [kernel.kallsyms][k] do_sys_poll 3.60% qemu-system-x86 [kernel.kallsyms][k] __pollwait 2.20% qemu-system-x86 [kernel.kallsyms][k] _raw_write_unlock_irqrestore 2.09% qemu-system-x86 libpthread-2.22.so [.] pthread_mutex_lock ... Found also: 1.) https://bugzilla.redhat.com/show_bug.cgi?id=949547 2.) https://www.kraxel.org/blog/2014/03/qemu-and-usb-tablet-cpu-consumtion/ After reading that I did the following: # On 10 Linux VMs I removed: # 1.) Serial device itself # 2.) PCI controller VirtIO serial # 3.) USB Mouse tablet # Positive consequences via munin monitoring: # Reduced fork rate: 40 => 13 # process states: running 15 => <1 # CÜU temperature: (core dependant) 65-70°C => 56-64°C # CPU usage: system: 47% => 15%, user: 76% => 50% # Context Switches: 20k => 7.5k # Interrupts: 16k => 9k # Load average: 2.8 => 1 => back at the level before one year!!! Any idea why the serial device/PCI controller and the USB mouse tablet consume so much CPU on latest kernel and/or qemu? Anyone has same experience? Thnx. Ciao, Gerhard
Re: [Qemu-devel] QEMU/KVM performance gets worser - high load - high interrupts - high context switches
Any comments? Ciao, Gerhard On 08.12.2015 10:39, Gerhard Wiesinger wrote: Hello, Yesterday I looked at my munin statistics on my KVM host and I swar that performance gets worser: load is getting higher, interrupts are getting higher and are high as well as context switches. VMs and applications didn't change that way. You can find graphics at: http://www.wiesinger.com/tmp/kvm/ Last spike I guess was upgrade from FC22 to FC23 or a kernel update. And it was even lower on older versions For me it looks like the high interrupt load and context switches are the root cause. Interrupts inside the VM are <100, so with 10 VMs I'm expecting 1000+baseload => <2000, see statistics below. All VMs are virtio on disk/network except one (IDE/rtl8139). # Host as well as all guests (except 2 VMs): uname -a Linux kvm 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux qemu-system-x86-2.4.1-1.fc23.x86_64 Platform: All VMs have the pc-i440fx-2.4 profile (I upgraded yesterday from pc-i440fx-2.3 without any change). Any ideas, anyone having same issues? Ciao, Gerhard kvm: no VM running r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 0 3308516 102408 379856800 012 197 679 0 0 99 0 0 0 0 0 3308516 102416 379856400 042 197 914 0 0 99 1 0 0 0 0 3308516 102416 379856800 0 0 190 791 0 0 100 0 0 2 0 0 3308484 102416 379856800 0 0 129 440 0 0 100 0 0 kvm: 2 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 2641464 103052 381470000 0 0 2715 5648 3 2 95 0 0 0 0 0 2641340 103052 381470000 0 0 2601 1 2 97 0 0 1 0 0 2641308 103052 381470000 0 5 2687 5708 3 2 95 0 0 0 0 0 2640620 103060 381462800 030 2779 5756 4 3 93 1 0 0 0 0 2640644 103060 381463600 0 0 2436 5364 1 2 97 0 0 1 0 0 2640520 103060 381463600 0 119 2734 5975 3 2 95 0 0 kvm: all 10 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 60408 78892 337198400 085 9015 17357 4 9 87 0 0 2 0 0 60408 78892 337196800 047 9375 17797 9 9 82 0 0 0 0 0 60472 78892 3372092004060 8882 17343 4 8 86 1 0 1 0 0 60316 78892 337208000 059 8863 17517 4 8 87 0 0 0 0 0 59540 78900 337209200 055 9135 17796 8 9 81 1 0 0 0 0 59168 78900 337211200 051 8931 17484 4 9 87 0 0 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz stepping: 7
[Qemu-devel] QEMU/KVM performance gets worser - high load - high interrupts - high context switches
Hello, Yesterday I looked at my munin statistics on my KVM host and I swar that performance gets worser: load is getting higher, interrupts are getting higher and are high as well as context switches. VMs and applications didn't change that way. You can find graphics at: http://www.wiesinger.com/tmp/kvm/ Last spike I guess was upgrade from FC22 to FC23 or a kernel update. And it was even lower on older versions For me it looks like the high interrupt load and context switches are the root cause. Interrupts inside the VM are <100, so with 10 VMs I'm expecting 1000+baseload => <2000, see statistics below. All VMs are virtio on disk/network except one (IDE/rtl8139). # Host as well as all guests (except 2 VMs): uname -a Linux kvm 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux qemu-system-x86-2.4.1-1.fc23.x86_64 Platform: All VMs have the pc-i440fx-2.4 profile (I upgraded yesterday from pc-i440fx-2.3 without any change). Any ideas, anyone having same issues? Ciao, Gerhard kvm: no VM running r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 0 3308516 102408 379856800 012 197 679 0 0 99 0 0 0 0 0 3308516 102416 379856400 042 197 914 0 0 99 1 0 0 0 0 3308516 102416 379856800 0 0 190 791 0 0 100 0 0 2 0 0 3308484 102416 379856800 0 0 129 440 0 0 100 0 0 kvm: 2 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 2641464 103052 381470000 0 0 2715 5648 3 2 95 0 0 0 0 0 2641340 103052 381470000 0 0 2601 1 2 97 0 0 1 0 0 2641308 103052 381470000 0 5 2687 5708 3 2 95 0 0 0 0 0 2640620 103060 381462800 030 2779 5756 4 3 93 1 0 0 0 0 2640644 103060 381463600 0 0 2436 5364 1 2 97 0 0 1 0 0 2640520 103060 381463600 0 119 2734 5975 3 2 95 0 0 kvm: all 10 VMs running procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 0 60408 78892 337198400 085 9015 17357 4 9 87 0 0 2 0 0 60408 78892 337196800 047 9375 17797 9 9 82 0 0 0 0 0 60472 78892 3372092004060 8882 17343 4 8 86 1 0 1 0 0 60316 78892 337208000 059 8863 17517 4 8 87 0 0 0 0 0 59540 78900 337209200 055 9135 17796 8 9 81 1 0 0 0 0 59168 78900 337211200 051 8931 17484 4 9 87 0 0 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz stepping: 7
[Qemu-devel] [PATCH] Fixed KVM problems with old DOS programs. Compatibility can be forced by module parameter.
Signed-off-by: Gerhard Wiesinger
---
arch/x86/kvm/svm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2f9ed1f..e0b00fc 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -198,6 +198,10 @@ static bool npt_enabled;
static int npt = true;
module_param(npt, int, S_IRUGO);
+/* allow backward compatibility with e.g. old DOS application */
+static int npt_task_switch_emulation = true;
+module_param(npt_task_switch_emulation, int, S_IRUGO);
+
/* allow nested virtualization in KVM/SVM */
static int nested = true;
module_param(nested, int, S_IRUGO);
@@ -1177,6 +1181,9 @@ static void init_vmcb(struct vcpu_svm *svm, bool
init_event)
if (npt_enabled) {
/* Setup VMCB for Nested Paging */
control->nested_ctl = 1;
+ if (!npt_task_switch_emulation) {
+ clr_intercept(svm, INTERCEPT_TASK_SWITCH);
+ }
clr_intercept(svm, INTERCEPT_INVLPG);
clr_exception_intercept(svm, PF_VECTOR);
clr_cr_intercept(svm, INTERCEPT_CR3_READ);
--
2.4.3
Re: [Qemu-devel] Kernel Panic on Yum update
On 15.05.2015 10:10, Paolo Bonzini wrote: On 15/05/2015 09:37, Gerhard Wiesinger wrote: Yes, yum takes memory. But there is ~2.2 GB virt memory available. That should be enough. Therefore I think it is a kernel problem. As in previous crashes on the mailing list there is a lot of swap available (2GB) which isn't touched in ANY way. Under normal conditions without yum: free totalusedfree shared buff/cache available Mem: 243036 132540 12716 15520 97780 74964 Swap: 2064380 0 2064380 Not all memory is the same. Some memory cannot be swapped, and some memory can be swapped to disk without a swap file (e.g. executables). Yes, I know the different memory types (pageable, non pageable, etc.). Failing an order 0 allocation is weird indeed, but this is a GFP_ATOMIC allocation so it's a bit less weird. Nevertheless the kernel should never go out of non pageable memory if a USER process requires memory (which is of course pageable). Ciao, Gerhard
Re: [Qemu-devel] Kernel Panic on Yum update
On 15.05.2015 08:51, Paolo Bonzini wrote: On 15/05/2015 08:34, Gerhard Wiesinger wrote: Helllo, I'm using latest qemu-kvm-2.3.0-3.fc21.x86_64 from libvirt repository (updated afterwards). Running yum regularly crashes the VM like below. VM is stripped down to minimum memory requirements (256MB) for owncloud. See below. Looks like a problem in virtio-net or a kernel bug with low memory situations. You're simply running out of memory. Yum can be a memory hog. Yes, yum takes memory. But there is ~2.2 GB virt memory available. That should be enough. Therefore I think it is a kernel problem. As in previous crashes on the mailing list there is a lot of swap available (2GB) which isn't touched in ANY way. Under normal conditions without yum: free totalusedfree shared buff/cache available Mem: 243036 132540 12716 15520 97780 74964 Swap: 2064380 0 2064380 And running it after reboot works fine (with all the services up). Ciao, Gerhard
[Qemu-devel] Kernel Panic on Yum update
Helllo, I'm using latest qemu-kvm-2.3.0-3.fc21.x86_64 from libvirt repository (updated afterwards). Running yum regularly crashes the VM like below. VM is stripped down to minimum memory requirements (256MB) for owncloud. See below. Looks like a problem in virtio-net or a kernel bug with low memory situations. Any ideas? Thank you. Ciao, Gerhard http://www.wiesinger.com/ kernel: swapper/0: page allocation failure: order:0, mode:0x20 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.7-200.fc21.x86_64 #1 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150414_141626-myhost.mydomain 04/01/2014 kernel: c35c12d2c14e1ce8 88000fc03ac8 8176f1f7 kernel: 0020 88000fc03b58 811a1c9e kernel: 0040 8800 88000ffcdb28 kernel: Call Trace: kernel: [] dump_stack+0x45/0x57 kernel: [] warn_alloc_failed+0xfe/0x170 kernel: [] __alloc_pages_nodemask+0x7ca/0xb10 kernel: [] ? nf_hook_slow+0x84/0x130 kernel: [] __alloc_page_frag+0x12f/0x150 kernel: [] __netdev_alloc_frag+0x2f/0x50 kernel: [] __alloc_rx_skb+0xe6/0x110 kernel: [] __netdev_alloc_skb+0x1f/0x40 kernel: [] page_to_skb+0x65/0x370 [virtio_net] kernel: [] virtnet_receive+0x2c1/0x980 [virtio_net] kernel: [] virtnet_poll+0x21/0x90 [virtio_net] kernel: [] net_rx_action+0x21a/0x350 kernel: [] __do_softirq+0x10b/0x2b0 kernel: [] irq_exit+0x125/0x130 kernel: [] do_IRQ+0x58/0xf0 kernel: [] common_interrupt+0x6d/0x6d kernel: [] ? hrtimer_start+0x18/0x20 kernel: [] ? native_safe_halt+0x6/0x10 kernel: [] ? rcu_eqs_enter+0xa3/0xb0 kernel: [] default_idle+0x1e/0xc0 kernel: [] arch_cpu_idle+0xf/0x20 kernel: [] cpu_startup_entry+0x37a/0x3c0 kernel: [] rest_init+0x77/0x80 kernel: [] start_kernel+0x4a4/0x4c5 kernel: [] ? early_idt_handlers+0x120/0x120 kernel: [] x86_64_start_reservations+0x2a/0x2c kernel: [] x86_64_start_kernel+0x152/0x175 kernel: swapper/0: page allocation failure: order:0, mode:0x20 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.7-200.fc21.x86_64 #1 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150414_141626-myhost.mydomain 04/01/2014 kernel: c35c12d2c14e1ce8 88000fc03ac8 8176f1f7 kernel: 0020 88000fc03b58 811a1c9e kernel: 0040 8800 88000ffcdb28 kernel: Call Trace: kernel: [] dump_stack+0x45/0x57 kernel: [] warn_alloc_failed+0xfe/0x170 kernel: [] __alloc_pages_nodemask+0x7ca/0xb10 kernel: [] ? nf_hook_slow+0x84/0x130 kernel: [] __alloc_page_frag+0x12f/0x150 kernel: [] __netdev_alloc_frag+0x2f/0x50 kernel: [] __alloc_rx_skb+0xe6/0x110 kernel: [] __netdev_alloc_skb+0x1f/0x40 kernel: [] page_to_skb+0x65/0x370 [virtio_net] kernel: [] virtnet_receive+0x2c1/0x980 [virtio_net] kernel: [] virtnet_poll+0x21/0x90 [virtio_net] kernel: [] net_rx_action+0x21a/0x350 kernel: [] __do_softirq+0x10b/0x2b0 kernel: [] irq_exit+0x125/0x130 kernel: [] do_IRQ+0x58/0xf0 kernel: [] common_interrupt+0x6d/0x6d kernel: [] ? hrtimer_start+0x18/0x20 kernel: [] ? native_safe_halt+0x6/0x10 kernel: [] ? rcu_eqs_enter+0xa3/0xb0 kernel: [] default_idle+0x1e/0xc0 kernel: [] arch_cpu_idle+0xf/0x20 kernel: [] cpu_startup_entry+0x37a/0x3c0 kernel: [] rest_init+0x77/0x80 kernel: [] start_kernel+0x4a4/0x4c5 kernel: [] ? early_idt_handlers+0x120/0x120 kernel: [] x86_64_start_reservations+0x2a/0x2c kernel: [] x86_64_start_kernel+0x152/0x175 kernel: swapper/0: page allocation failure: order:0, mode:0x20 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.7-200.fc21.x86_64 #1 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150414_141626-myhost.mydomain 04/01/2014 kernel: c35c12d2c14e1ce8 88000fc03ac8 8176f1f7 kernel: 0020 88000fc03b58 811a1c9e kernel: 0040 8800 88000ffcdb28 kernel: Call Trace: kernel: [] dump_stack+0x45/0x57 kernel: [] warn_alloc_failed+0xfe/0x170 kernel: [] __alloc_pages_nodemask+0x7ca/0xb10 kernel: [] ? nf_hook_slow+0x84/0x130 kernel: [] __alloc_page_frag+0x12f/0x150 kernel: [] __netdev_alloc_frag+0x2f/0x50 kernel: [] __alloc_rx_skb+0xe6/0x110 kernel: [] __netdev_alloc_skb+0x1f/0x40 kernel: [] page_to_skb+0x65/0x370 [virtio_net] kernel: [] virtnet_receive+0x2c1/0x980 [virtio_net] kernel: [] virtnet_poll+0x21/0x90 [virtio_net] kernel: [] net_rx_action+0x21a/0x350 kernel: [] __do_softirq+0x10b/0x2b0 kernel: [] irq_exit+0x125/0x130 kernel: [] do_IRQ+0x58/0xf0 kernel: [] common_interrupt+0x6d/0x6d kernel: [] ? hrtimer_start+0x18/0x20 kernel: [] ? native_safe_halt+0x6/0x10 kernel: [] ? rcu_eqs_enter+0xa3/0xb0 kernel: [] default_idle+0x1e/0xc0 kernel: [] arch_cpu_idle+0xf/0x20 kernel: [] cpu_startup_entry+0x37a/0x3c0 kernel: [] rest_init+0x77/0x80 kernel: [] start_kernel+0x4a4/0x4c5 kernel: [] ? early_idt_handlers+0x120/0x120 kernel: [
Re: [Qemu-devel] Fedora Virt preview and qemu 2.2.1 update
On 17.03.2015 14:59, Cole Robinson wrote: On 03/16/2015 06:20 PM, Gerhard Wiesinger wrote: On 16.03.2015 19:49, Cole Robinson wrote: Since 2.3 rc0 should be out tomorrow, I'll just wait for that to be released and build it for rawhide/f22 and virt-preview Shouldn't we have a 2.2.1 version, too? A reference point between 2.1 and the not yet released version 2.3 version would be fine. The repos don't really work like that. If I build 2.2.1, then soon after build 2.3-rc0, the 2.2.1 packages will disappear from the repos. In the case of rawhide you could still grab it from koji, but for virt-preview the 2.2.1 package would be gone. So I don't see the usefulness in putting in effort to package 2.2.1 when it will only be available for a very brief window of time. Yes, but shouldn't be there a difference between rawhide (e.g. 2.3-rc0) and fedora virt preview library (e.g. currently 2.2.1)? Or is rawhide everything and fedora-virt-preview.repo only the virt part of rawhide? https://fedoraproject.org/wiki/Virtualization_Preview_Repository http://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo Nevertheless I don't see any advantages releasing RC production quality to the rawhide repository as we expect the release soon. As my question regarding "support" for virt preview was not answered when I had problems and tried it I think I'll switch back to Fedora supported repos. Thank you anyway. Ciao, Gerhard
Re: [Qemu-devel] Fedora Virt preview and qemu 2.2.1 update
On 16.03.2015 19:49, Cole Robinson wrote: Since 2.3 rc0 should be out tomorrow, I'll just wait for that to be released and build it for rawhide/f22 and virt-preview Shouldn't we have a 2.2.1 version, too? A reference point between 2.1 and the not yet released version 2.3 version would be fine. Thank you. Ciao, Gerhard
[Qemu-devel] Fedora Virt preview and qemu 2.2.1 update
Hello, Any updates for the http://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo repo to qemu 2.2.1 planned? Thank you. Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 03.03.2015 14:18, Gerhard Wiesinger wrote: On 03.03.2015 13:28, Gerhard Wiesinger wrote: On 03.03.2015 10:12, Gerhard Wiesinger wrote: On 02.03.2015 18:15, Gerhard Wiesinger wrote: On 02.03.2015 16:52, Gerhard Wiesinger wrote: On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3.) 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3b.) Still happened again at the nightly backup with same configuration as in 3.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: no OOM problem, ping ok, no reaction, BUT CRASHED again 3c.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: OOM problem, no crash postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Free swap = 905924kB Total swap = 1081340kB Out of memory: Kill process 19312 (pg_dump) score 142 or sacrifice child Killed process 19312 (pg_dump) total-vm:384516kB, anon-rss:119260kB, file-rss:0kB An OOM should not occour: https://www.kernel.org/doc/gorman/html/understand/understand016.html Is there enough swap space left (nr_swap_pages > 0) ? If yes, not OOM Why does an OOM condition occour? Looks like a bug in the kernel? Any ideas? # Allocating 800MB, killed by OOM killer ./mallocsleep 805306368 Killed Out of memory: Kill process 27160 (mallocsleep) score 525 or sacrifice child Killed process 27160 (mallocsleep) total-vm:790588kB, anon-rss:214948kB, file-rss:0kB free -m totalusedfree shared buff/cache available Mem:363 23 252 23 87 295 Swap: 1055 134 921 ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1392 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1392 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # Maschine is getting inresponsive and stalls for seconds, but never reaches more than 1055MB swap size (+ 384MB RAM) vmstat 1 procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 136472 241196 1400 985444 57 172467 211 261 2 3 91 2 2 0 0 136472 241228 1400 9854000 0 0 30 48 0 0 100 0 0 0 0 136472 241228 1408 9853200 052 53 51 0 0 89 11 0 0 0 136472 241224 1408 9854000 0 112 44 92 0 0 100 0 0 0 0 136472 241224 1408 9854000 0 0 24 32 0 0 100 0 0 0 0 136472 241352 1408 9854000 0 0 31 44 0 1 100 0 0 0 0 136472 241328 1408 9854000 03
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 03.03.2015 13:28, Gerhard Wiesinger wrote: On 03.03.2015 10:12, Gerhard Wiesinger wrote: On 02.03.2015 18:15, Gerhard Wiesinger wrote: On 02.03.2015 16:52, Gerhard Wiesinger wrote: On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3.) 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3b.) Still happened again at the nightly backup with same configuration as in 3.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: no OOM problem, ping ok, no reaction, BUT CRASHED again 3c.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: OOM problem, no crash postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Free swap = 905924kB Total swap = 1081340kB Out of memory: Kill process 19312 (pg_dump) score 142 or sacrifice child Killed process 19312 (pg_dump) total-vm:384516kB, anon-rss:119260kB, file-rss:0kB An OOM should not occour: https://www.kernel.org/doc/gorman/html/understand/understand016.html Is there enough swap space left (nr_swap_pages > 0) ? If yes, not OOM Why does an OOM condition occour? Looks like a bug in the kernel? Any ideas? # Allocating 800MB, killed by OOM killer ./mallocsleep 805306368 Killed Out of memory: Kill process 27160 (mallocsleep) score 525 or sacrifice child Killed process 27160 (mallocsleep) total-vm:790588kB, anon-rss:214948kB, file-rss:0kB free -m totalusedfree shared buff/cache available Mem:363 23 252 23 87 295 Swap: 1055 134 921 ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1392 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1392 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # Maschine is getting inresponsive and stalls for seconds, but never reaches more than 1055MB swap size (+ 384MB RAM) vmstat 1 procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 136472 241196 1400 985444 57 172467 211 261 2 3 91 2 2 0 0 136472 241228 1400 9854000 0 0 30 48 0 0 100 0 0 0 0 136472 241228 1408 9853200 052 53 51 0 0 89 11 0 0 0 136472 241224 1408 9854000 0 112 44 92 0 0 100 0 0 0 0 136472 241224 1408 9854000 0 0 24 32 0 0 100 0 0 0 0 136472 241352 1408 9854000 0 0 31 44 0 1 100 0 0 0 0 136472 241328 1408 9854000 036 97 142 0 1 99 0 0 0 0 13647
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 03.03.2015 10:12, Gerhard Wiesinger wrote: On 02.03.2015 18:15, Gerhard Wiesinger wrote: On 02.03.2015 16:52, Gerhard Wiesinger wrote: On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3.) 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3b.) Still happened again at the nightly backup with same configuration as in 3.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: no OOM problem, ping ok, no reaction, BUT CRASHED again 3c.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: OOM problem, no crash postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Free swap = 905924kB Total swap = 1081340kB Out of memory: Kill process 19312 (pg_dump) score 142 or sacrifice child Killed process 19312 (pg_dump) total-vm:384516kB, anon-rss:119260kB, file-rss:0kB An OOM should not occour: https://www.kernel.org/doc/gorman/html/understand/understand016.html Is there enough swap space left (nr_swap_pages > 0) ? If yes, not OOM Why does an OOM condition occour? Looks like a bug in the kernel? Any ideas? Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 02.03.2015 18:15, Gerhard Wiesinger wrote: On 02.03.2015 16:52, Gerhard Wiesinger wrote: On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3.) 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3b.) Still happened again at the nightly backup with same configuration as in 3.) configuration 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1, pc-i440fx-2.2: no OOM problem, ping ok, no reaction, BUT CRASHED again SYSRQ: no reaction of the VM virsh send-key vm KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump vm file.core error: Failed to core dump domain vm to file.core error: internal error: unable to execute QEMU command 'migrate': State blocked by non-migratable device ':00:09.0/ich9_ahci' Removed the SATA controller, dump should work for the future. Any futher ideas? Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 02.03.2015 16:52, Gerhard Wiesinger wrote: On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 3.) 384MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 02.03.2015 10:26, Paolo Bonzini wrote: On 01/03/2015 11:36, Gerhard Wiesinger wrote: So far it happened only the PostgreSQL database VM. Kernel is alive (ping works well). ssh is not working. console window: after entering one character at login prompt, then crashed: [1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or sacrifice child [1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB, anon-rss: 162712kB, file-rss: 220kB Can you get a vmcore or at least sysrq-t output? Yes, next time it happens I can analyze it. I think there are 2 problems: 1.) OOM (Out of Memory) problem with the low memory settings and kernel settings (see below) 2.) Instability problem which might have a dependency to 1.) What I've done so far (thanks to Andrey Korolyov for ideas and help): a.) Updated maschine type from pc-0.15 to pc-i440fx-2.2 virsh dumpxml database | grep "hvm virsh edit database virsh dumpxml database | grep "hvm SMBIOS is updated therefore from 2.4 to 2.8: dmesg|grep -i SMBIOS [0.00] SMBIOS 2.8 present. b.) Switched to tsc clock, kernel parameters: clocksource=tsc nohz=off highres=off c.) Changed overcommit to 1 echo "vm.overcommit_memory = 1" > /etc/sysctl.d/overcommit.conf d.) Tried 1 VCPU instead of 2 e.) Installed 512MB vRAM instead of 384MB f.) Prepared for sysrq and vmcore echo "kernel.sysrq = 1" > /etc/sysctl.d/sysrq.conf sysctl -w kernel.sysrq=1 virsh send-key database KEY_LEFTALT KEY_SYSRQ KEY_T virsh dump domain-name /tmp/dumpfile g.) Further ideas, not yet done: disable memory balooning by blacklisting baloon driver or remove from virsh xml config Summary: 1.) 512MB, tsc timer, 1VCPU, vm.overcommit_memory = 1: no OOM problem, no crash 2.) 512MB, kvm_clock, 2VCPU, vm.overcommit_memory = 1: no OOM problem, no crash So the OOM problem seems to be solved (at least it didn't happen so far) by installing 512MB RAM and setting vm.overcommit_memory = 1 (I guess just setting overcommit would be fine, too). Instability didn't occour so far. If I can't reproduce it, I'll revert the settings. Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 16.02.2015 16:29, Paolo Bonzini wrote:
On 16/02/2015 16:09, Gerhard Wiesinger wrote:
On 16.02.2015 15:18, Paolo Bonzini wrote:
On 15/02/2015 09:18, Gerhard Wiesinger wrote:
Can you grab some random backtraces ("thread apply all bt full") with
gdb?
Very low load on the machine, so I guess most will be sleeping and hard
to catch non sleeping ones. See below
This likely means that the 100% threads are not the I/O (event loop)
threads, but the VCPU threads.
ok, happened again, details below.
Any further ideas from the stack traces?
So far it happened only the PostgreSQL database VM. Kernel is alive
(ping works well). ssh is not working.
console window: after entering one character at login prompt, then crashed:
[1438.384864] Out of memory: Kill process 10115 (pg_dump) score 112 or
sacrifice child
[1438.384990] Killed process 10115 (pg_dump) total-vm: 340548kB,
anon-rss: 162712kB, file-rss: 220kB
VM uptime is ~1 day, 2 cores 100%CPU.
VM is very stripped down, nevertheless is should have enough memory (and
also swap). Looks like it crashed at the nighlty backup (pg_dumpall),
command is: ssh -x ${REMOTE_USER}@${REMOTE_HOST} "pg_dumpall" | bzip2 -9
> ${DEST_SQL}
free
totalusedfree shared buff/cache
available
Mem: 372264 28536 214780 20884 128948 303360
Swap: 1081340 0 1081340
Ciao,
Gerhard
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x7feee62412c1 in ppoll () from /lib64/libc.so.6
Thread 4 (Thread 0x7feed3fff700 (LWP 4636)):
#0 0x7feee6242977 in ioctl () at /lib64/libc.so.6
#1 0x7feef11d1c35 in kvm_vcpu_ioctl ()
#2 0x7feef11d1cec in kvm_cpu_exec ()
#3 0x7feef11bfb02 in qemu_kvm_cpu_thread_fn ()
#4 0x7feeefcb352a in start_thread () at /lib64/libpthread.so.0
#5 0x7feee624c79d in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7feed37fe700 (LWP 4637)):
#0 0x7feee6242977 in ioctl () at /lib64/libc.so.6
#1 0x7feef11d1c35 in kvm_vcpu_ioctl ()
#2 0x7feef11d1cec in kvm_cpu_exec ()
#3 0x7feef11bfb02 in qemu_kvm_cpu_thread_fn ()
#4 0x7feeefcb352a in start_thread () at /lib64/libpthread.so.0
#5 0x7feee624c79d in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7feed1bff700 (LWP 4653)):
#0 0x7feeefcb8590 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1 0x7feef1466d79 in qemu_cond_wait ()
#2 0x7feef13eadd3 in vnc_worker_thread_loop ()
#3 0x7feef13eb1b8 in vnc_worker_thread ()
#4 0x7feeefcb352a in start_thread () at /lib64/libpthread.so.0
#5 0x7feee624c79d in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7feef103fa80 (LWP 4563)):
#0 0x7feee62412c1 in ppoll () at /lib64/libc.so.6
#1 0x7feef13fc89c in qemu_poll_ns ()
#2 0x7feef13fc034 in main_loop_wait ()
#3 0x7feef1197cdd in main ()
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 16.02.2015 15:18, Paolo Bonzini wrote:
On 15/02/2015 09:18, Gerhard Wiesinger wrote:
Can you grab some random backtraces ("thread apply all bt full") with gdb?
Very low load on the machine, so I guess most will be sleeping and hard
to catch non sleeping ones. See below
For the records: gdb -p 14139 -ex 'thread apply all bt full' -batch
What is the libvirt XML or qemu command line?
See below.
Kernel (host/guest): 3.18.6-200.fc21.x86_64 #1 SMP
qemu-kvm-2.2.0-5.fc21.x86_64
Bug 1178975 - endless loop in clock_gettime() on a kvm-based VM
https://bugzilla.redhat.com/show_bug.cgi?id=1178975
is fixed (didn't occour with the test program posted at
https://bugzilla.redhat.com/show_bug.cgi?id=1178975#c28 in 30min,
happened before reproduceable in 2min, still running)
So I guess there is another problem in the kernel with volatile and gcc
optimizations (or maybe in qemu-KVM)
No, this doesn't look like volatile.
But why 100% on 2 cores?
There were also recent bugfixes with optimizations in gcc-4.9.2-6.fc21
maybe we hit one of these.
- update from the 4.9 branch
- PRs c++/54442, c++/64514, c++/64521, c++/64901, c/57653, c/61553,
c/64766,
c/64778, c/64824, c/64868, debug/64511, debug/64663, fortran/56867,
fortran/57023, fortran/60922, fortran/62044, fortran/63733,
fortran/64230, fortran/64528, fortran/64771, ipa/63970, ipa/64068,
ipa/64559, libstdc++/64476, libstdc++/64584, libstdc++/64585,
libstdc++/64646, libstdc++/64649, libstdc++/64680, middle-end/63704,
middle-end/64391, middle-end/64421, middle-end/64734,
rtl-optimization/61058, rtl-optimization/63637,
rtl-optimization/64286, rtl-optimization/64557, target/61413,
target/63424, target/64358, target/64479, target/64505, target/64513,
target/64580, target/64795, target/64882, target/64938, target/64979,
testsuite/64712, tree-optimization/64563
Ciao,
Gerhard
/usr/bin/qemu-system-x86_64 -machine accel=kvm -name myvm -S -machine
pc-0.15,accel=kvm,usb=off -m 384 -realtime mlock=off -smp
2,sockets=2,cores=1,threads=1 -uuid b40e77d3-cd86-4d59-9ee4-5756ec88bf99
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/myvm.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot menu=on,strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
lsi,id=scsi0,bus=pci.0,addr=0x6 -device ahci,id=ahci0,bus=pci.0,addr=0x9
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
if=none,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
file=/var/lib/libvirt/images/myvm.img,if=none,id=drive-virtio-disk0,format=qcow2
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:aa:bb:cc,bus=pci.0,addr=0x8
-netdev tap,fd=35,id=hostnet1,vhost=on,vhostfd=36 -device
virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:aa:bb:cd,bus=pci.0,addr=0x7
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0
-vnc 127.0.0.1:9 -k de -device
VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
myvm
b40e77d3-cd86-4d59-9ee4-5756ec88bf99
Fedora 21
393216
393216
2
/machine
hvm
destroy
restart
restart
/usr/bin/qemu-kvm
function='0x0'/>
function='0x1'/>
function='0x2'/>
function='0x0'/>
function='0x0'/>
function='0x0'/>
function='0x0'/>
function='0x0'/>
keymap='de'>
function='0x0'/>
function='0x0'/>
Thread 11 (Thread 0x7ffe8bdfe700 (LWP 14147)):
#0 0x7ffe9dca8977 in ioctl () at /lib64/libc.so.6
#1 0x7ffea8c37c35 in kvm_vcpu_ioctl ()
#2 0x7ffea8c37cec in kvm_cpu_exec ()
#3 0x7ffea8c25b02 in qemu_kvm_cpu_thread_fn ()
#4 0x7ffea771952a in start_thread () at /lib64/libpthread.so.0
#5 0x7ffe9dcb279d in clone () at /lib64/libc.so.6
Thread 10 (Thread 0x7ffe8b5fd700 (LWP 14148)):
#0 0x7ffe9dca8977 in ioctl () at /lib64/libc.so.6
#1 0x7ffea8c37c35 in kvm_vcpu_ioctl ()
#2 0x7ffea8c37c
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 14.01.2015 10:15, Gerhard Wiesinger wrote:
On 14.01.2015 01:59, Laine Stump wrote:
Take a look at the following kernel bug. It specifically deals with a
hang in gettimeofday() in a KVM guest:
https://bugzilla.redhat.com/show_bug.cgi?id=1178975
There is a link to a patched kernel you can try; it fixed my problems (I
was repeatedly getting hangs in python-urlgrabber during yum updates on
F21).
Looks to be fixed, commented in:
https://bugzilla.redhat.com/show_bug.cgi?id=1178975
Installed kernels.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8575247
There seems to be another problem. My PostgreSQL server VM still crashes
(2 times).
1.) First time crash: no reaction at all in KVM console, no network access
2.) Second time "crash":
- KVM console 2 characters could be entered, then console was dead forever
- ping works
- ssh not
- host: 100% cpu on 2 cores
strace -y -p on kvm host (loops through this):
read(7, 0x7fffb862bf20, 16) = -1 EAGAIN (Resource
temporarily unavailable)
ioctl(11, KVM_GET_DIRTY_LOG, 0x7fffb862bd30) = 0
ioctl(11, KVM_GET_DIRTY_LOG, 0x7fffb862bd30) = 0
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
ppoll([{fd=98, events=POLLIN|POLLERR|POLLHUP},
{fd=89, events=POLLIN|POLLERR|POLLHUP},
{fd=88, events=POLLIN|POLLERR|POLLHUP},
{fd=87, events=POLLIN|POLLERR|POLLHUP},
{fd=86, events=POLLIN|POLLERR|POLLHUP},
{fd=85, events=POLLIN|POLLERR|POLLHUP},
{fd=84, events=POLLIN|POLLERR|POLLHUP},
{fd=83, events=POLLIN|POLLERR|POLLHUP},
{fd=82, events=POLLIN|POLLERR|POLLHUP},
{fd=81, events=POLLIN|POLLERR|POLLHUP},
{fd=80, events=POLLIN|POLLERR|POLLHUP},
{fd=79, events=POLLIN|POLLERR|POLLHUP},
{fd=78, events=POLLIN|POLLERR|POLLHUP},
{fd=77, events=POLLIN|POLLERR|POLLHUP},
{fd=76, events=POLLIN|POLLERR|POLLHUP},
{fd=75, events=POLLIN|POLLERR|POLLHUP},
{fd=74, events=POLLIN|POLLERR|POLLHUP},
{fd=73, events=POLLIN|POLLERR|POLLHUP},
{fd=72, events=POLLIN|POLLERR|POLLHUP},
{fd=71, events=POLLIN|POLLERR|POLLHUP},
{fd=70, events=POLLIN|POLLERR|POLLHUP},
{fd=69, events=POLLIN|POLLERR|POLLHUP},
{fd=68, events=POLLIN|POLLERR|POLLHUP},
{fd=67, events=POLLIN|POLLERR|POLLHUP},
{fd=66, events=POLLIN|POLLERR|POLLHUP},
{fd=65, events=POLLIN|POLLERR|POLLHUP},
{fd=64, events=POLLIN|POLLERR|POLLHUP},
{fd=63, events=POLLIN|POLLERR|POLLHUP},
{fd=62, events=POLLIN|POLLERR|POLLHUP},
{fd=61, events=POLLIN|POLLERR|POLLHUP},
{fd=60, events=POLLIN|POLLERR|POLLHUP},
{fd=59, events=POLLIN|POLLERR|POLLHUP}, ...], 71,
{0, 124112228}, NULL, 8) = 1 ([...], left {0, 124090614})
write(7, "\1\0\0\0\0\0\0\0", 8) = 8
read(6, "\1\0\0\0\0\0\0\0", 512) = 8
write(7, "\1\0\0\0\0\0\0\0", 8) = 8
Kernel (host/guest): 3.18.6-200.fc21.x86_64 #1 SMP
qemu-kvm-2.2.0-5.fc21.x86_64
Bug 1178975 - endless loop in clock_gettime() on a kvm-based VM
https://bugzilla.redhat.com/show_bug.cgi?id=1178975
is fixed (didn't occour with the test program posted at
https://bugzilla.redhat.com/show_bug.cgi?id=1178975#c28 in 30min,
happened before reproduceable in 2min, still running)
So I guess there is another problem in the kernel with volatile and gcc
optimizations (or maybe in qemu-KVM)
Any ideas?
Any other bug reports like this?
Thank you.
Ciao,
Gerhard
-- http://www.wiesinger.com/
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 14.01.2015 18:52, Juan Quintela wrote: Juan Quintela wrote: I forgot tell on the previous patch, I am using 2vcpus. with a single vcpu I have been unable to trigger this bug. There is already a fix with a new patched kernel available for the guest, see the bugzilla entry and my posts in this thread. Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 14.01.2015 01:59, Laine Stump wrote: Take a look at the following kernel bug. It specifically deals with a hang in gettimeofday() in a KVM guest: https://bugzilla.redhat.com/show_bug.cgi?id=1178975 There is a link to a patched kernel you can try; it fixed my problems (I was repeatedly getting hangs in python-urlgrabber during yum updates on F21). Looks to be fixed, commented in: https://bugzilla.redhat.com/show_bug.cgi?id=1178975 Installed kernels. http://koji.fedoraproject.org/koji/taskinfo?taskID=8575247 Time to release a new official kernel :-) Thanx for the comments. Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 13.01.2015 22:16, Paolo Bonzini wrote:
On 13/01/2015 22:14, Gerhard Wiesinger wrote:
I also had a look at the kernel code again:
http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493
499 do {
500 seq = read_seqcount_begin(&tk_core.seq);
501
502 ts->tv_sec = tk->xtime_sec;
503 nsecs = timekeeping_get_ns(&tk->tkr);
504
505 } while (read_seqcount_retry(&tk_core.seq, seq));
So it looks like that the seqcount always changes and therefore loops
forever here (as far as I digged it down this is the only loop here).
Might be something wrong with the memory barriers in recent qemu-kvm
releases?
No, that's not possible. Unless you pause/resume or migrate the VM, all
of the handling of kvmclock is entirely in the kernel.
Any other possible explaination of the problem?
Had a look at the diff (I guess the right file at least in qemu tree):
# no critical changes IHMO here
git diff -u v1.6.2..v2.1.2 ./hw/i386/kvm/clock.c
Trying to reproduce with a loop:
#include
#include
int main(int argc, char* argv[])
{
struct timeval tv;
int i = 0;
for (;;)
{
gettimeofday(&tv, 0);
++i;
if (i >= 1000)
{
i = 0;
printf("%i\n", (int)tv.tv_sec);
}
}
return 0;
}
As I wrote this: "First tests seem to run well, so no quick win ", I
could reproduce it with a stall in 318s :-)
(gdb) bt
#0 0x7fff6d9fefff in gettimeofday ()
#1 0x004005ad in main (argc=1, argv=0x7fff6d9b28b8) at
gettimeofdayloop.c:10
So we have at least a testcase which is quickly to reproduce.
So we are digging down my second findings about a major bug in qemu-kvm :-)
Can someone try, too?
Ciao,
Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 13.01.2015 21:48, Paolo Bonzini wrote:
On 13/01/2015 21:13, Gerhard Wiesinger wrote:
It happens also with qemu-kvm 2.2.0 on another VM where also PostgreSQL
is running:
(gdb) bt
#0 0x7fff9a1feff4 in gettimeofday ()
#1 0x006d425e in GetCurrentTimestamp () at timestamp.c:1274
What we know:
OK : F20: 3.17.6-200.fc20.x86_64 on guest/host,
qemu-kvm-1.6.2-10.fc20.x86_64 on host
NOK: F21: 3.17.7-300.fc21.x86_64 on guest/host,
qemu-kvm-2.1.2-7.fc21.x86_64 on host
NOK: F21: 3.17.8-300.fc21.x86_64 on guest/host,
qemu-kvm-2.2.0-1.fc21.x86_64 on host
No one less can reproduce or has similar problems?
Any further ideas?
Hmm, too bad. :(
Any chance you can try with 1.7 and 2.0 releases? Cole, perhaps you
help building some RPMS for Gerhard?
Yes, I can try. RPMs would be fine.
Don't know if it is related, but on another VM maschine I was getting
the following 75s after reboot:
[ 78.857006] INFO: rcu_sched self-detected stall on CPU { 0} (t=6
jiffies g=1966 c=1965 q=0)
[ 258.860006] INFO: rcu_sched self-detected stall on CPU { 0} (t=240003
jiffies g=1966 c=1965 q=0)
I also had a look at the kernel code again:
http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493
499 do {
500 seq = read_seqcount_begin(&tk_core.seq);
501
502 ts->tv_sec = tk->xtime_sec;
503 nsecs = timekeeping_get_ns(&tk->tkr);
504
505 } while (read_seqcount_retry(&tk_core.seq, seq));
So it looks like that the seqcount always changes and therefore loops
forever here (as far as I digged it down this is the only loop here).
Might be something wrong with the memory barriers in recent qemu-kvm
releases?
Ciao,
Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 12.01.2015 12:41, Gerhard Wiesinger wrote: On 08.01.2015 23:28, Gerhard Wiesinger wrote: I'll keep you up to date in the next days whether it happens again or not. With qemu-kvm 2.2.0 release from the above repository the 100% usage didn't happen so far (although I had to reboot after kernel update). It happens also with qemu-kvm 2.2.0 on another VM where also PostgreSQL is running: (gdb) bt #0 0x7fff9a1feff4 in gettimeofday () #1 0x006d425e in GetCurrentTimestamp () at timestamp.c:1274 What we know: OK : F20: 3.17.6-200.fc20.x86_64 on guest/host, qemu-kvm-1.6.2-10.fc20.x86_64 on host NOK: F21: 3.17.7-300.fc21.x86_64 on guest/host, qemu-kvm-2.1.2-7.fc21.x86_64 on host NOK: F21: 3.17.8-300.fc21.x86_64 on guest/host, qemu-kvm-2.2.0-1.fc21.x86_64 on host No one less can reproduce or has similar problems? Any further ideas? BTW: I'm running ntp in the following manner: internet <=> ntp server in VM <=> ntp client on KVM host (firewall runs in KVM) Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 12.01.2015 12:46, Paolo Bonzini wrote: On 12/01/2015 12:41, Gerhard Wiesinger wrote: Updated to 2.2.0 qemu-kvm release, worked seemless so far for all VMs. I'll keep you up to date in the next days whether it happens again or not. With qemu-kvm 2.2.0 release from the above repository the 100% usage didn't happen so far (although I had to reboot after kernel update). So it looks that qemu-kvm 2.1.x has major bugs regarding timer handling. Any backporting planned? That's difficult without bisection pointing out where the bugs were fixed. 2.1.3 is scheduled real soon now and it will be the last release from the 2.1.x branch. So no security updates planned for 2.1.x afterwards? For Fedora: Update for 2.2.x for the regulary update repo planned? Will updated for 2.2.x also be released in the preview repos? http://fedoraproject.org/wiki/Virtualization_Preview_Repository Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 08.01.2015 23:28, Gerhard Wiesinger wrote: On 08.01.2015 19:22, Paolo Bonzini wrote: Indeed. Can you try the 2.2.0 qemu-kvm release, available in the fedora-virt-preview repository? http://fedoraproject.org/wiki/Virtualization_Preview_Repository Updated to 2.2.0 qemu-kvm release, worked seemless so far for all VMs. I'll keep you up to date in the next days whether it happens again or not. With qemu-kvm 2.2.0 release from the above repository the 100% usage didn't happen so far (although I had to reboot after kernel update). So it looks that qemu-kvm 2.1.x has major bugs regarding timer handling. Any backporting planned? Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 08.01.2015 19:22, Paolo Bonzini wrote: On 08/01/2015 19:12, Gerhard Wiesinger wrote: Since kernels were the same on FC20/F21 and qemu/kvm changed from 1.6.2 to 2.1.2 I guess the topic seems to be there. Also newer gcc might be a topic. Indeed. Can you try the 2.2.0 qemu-kvm release, available in the fedora-virt-preview repository? http://fedoraproject.org/wiki/Virtualization_Preview_Repository Updated to 2.2.0 qemu-kvm release, worked seemless so far for all VMs. I'll keep you up to date in the next days whether it happens again or not. BTW: Has something changed in the time code area between 1.6.2 and 2.1.2? Thank you so far. Ciao, Gerhard
Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
On 08.01.2015 18:24, Paolo Bonzini wrote: On 08/01/2015 14:36, Gerhard Wiesinger wrote: Quitting and reattaching gdb also hangs here, so gettimeofday takes 100% CPU and never ends! Therefore I guess this is a problem either in the Linux kernel or in QEMU/KVM. What kernel are you running on (and were you running on)? Can you try F20 host and F21 guest or vice versa? Hello Paolo, Always latest available stable versions (kernel/qemu-kvm): F20: 3.17.6-200.fc20.x86_64 on guest/host, qemu-kvm-1.6.2-10.fc20.x86_64 on host F21: 3.17.7-300.fc21.x86_64 on guest/host, qemu-kvm-2.1.2-7.fc21.x86_64 on host (I had also 3.17.6-300.fc21.x86_64 and it happended there, too). The topic is: it happens after some time (e.g. hours to days) It is production environment running around 10VMs and I want to avoid many experiments there. Since kernels were the same on FC20/F21 and qemu/kvm changed from 1.6.2 to 2.1.2 I guess the topic seems to be there. Also newer gcc might be a topic. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/time/timekeeping.c?id=refs/tags/v3.17.7#n695 I guess it hangs in the do/while loop here: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/time/timekeeping.c?id=refs/tags/v3.17.7#n493 Ciao, Gerhard
[Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever
Hello, After upgrading my KVM environment from Fedora 20 to Fedora 21 up2date (hosts and guests, Intel CPU) I've the following problem: 1.) On the database VM PostgresSQL e.g. 2 processes hang with 100% cpu 2.) On the monitoring VM Munin/RRDtool also hangs with 100% cpu Killing of processes is not possible, only reboot helps. But I nailed it down to the following: yum install strace strace -y -p339 Process 339 attached # no system calls here ^CProcess 339 detached Going deeper: yum --enablerepo fedora-debuginfo,updates-debuginfo install gdb postgresql-debuginfo gdb postgres 339 (gdb) bt #0 0x7fbf8ff8 in gettimeofday () #1 0x006d425e in GetCurrentTimestamp () at timestamp.c:1274 (gdb) frame 1 #1 0x006d425e in GetCurrentTimestamp () at timestamp.c:1274 1274gettimeofday(&tp, NULL); (same on second process here) Quitting and reattaching gdb also hangs here, so gettimeofday takes 100% CPU and never ends! Therefore I guess this is a problem either in the Linux kernel or in QEMU/KVM. It might be the case that something changed in timer handling or some default changed here. VMs are time syncrhonized with NTP so this might also be a problem that the syscall hangs here. Workaround when it happens: reboot Any further ideas? Thank you. Ciao, Gerhard
Re: [Qemu-devel] uvesafb doesn't work with seabios
On 13.05.2014 17:41, Kevin O'Connor wrote: The x86emu code does not properly emulate "leal" (as near as I can tell it treats it as a "leaw" instead), which leads to all sorts of bizarre behavior when it tries to interpret the code. This type of issue has occurred for a bunch of instructions (on both x86emu and on an emulator Windows uses) and we've worked around it in SeaVGABIOS with a combination of gcc compiler flags and by post processing gcc's assembler to remove some troublesome instructions. Unfortunately, I don't know of any way to convince gcc to not emit the "leal" instruction and the instruction appears too complex to readily patch out of the assembler. Can't that wrong behaviour of "leal" instruction be fixed in qemu? Ciao, Gerhard
Re: [Qemu-devel] Windows XP Setup hangs on Fedora FC20 install
On 17.03.2014 13:31, Cole Robinson wrote: Works fine here but I'm using AMD. Please file a Fedora bug against qemu, and include: - full qemu command line (if using libvirt: /var/log/libvirt/qemu/$vmname.log) - Any qemu stdout/stderr output - Check dmesg for any kvm errors - Try booting an older Fedora 20 kernel and see if it makes any difference - Optionally try a rawhide kernel: sudo yum install fedora-release-rawhide && sudo yum --enablrepo=rawhide update kernel Hello Cole, I tried it on a Fedora 20 installation with latest updates (same software version) with an AMD CPU and I can confirm that it works, too. Can you try it on Intel based CPUs, too? Thank you. Ciao, Gerhard
Re: [Qemu-devel] Windows XP Setup hangs on Fedora FC20 install
On 16.03.2014 18:50, Paolo Bonzini wrote: Il 16/03/2014 13:40, Gerhard Wiesinger ha scritto: Hello, I tried to install XP SP3 (also tried XP SP2) on a new VM (IDE, 1GB RAM, VMVGA, more details can be provided if necessary) on Fedora 20 (Packages below), but it hangs on "Installing Windows/Installing Devices". Was reproduceable 2 times. Anyone has similar problems? What version worked for you? Does it work with vmware VGA? Hello Paolo, I didn't install XP for a long time, so I don't have any reference version which worked well. As I wrote I tested with VMVGA which didn't work. Thank you. Ciao, Gerhard
[Qemu-devel] Windows XP Setup hangs on Fedora FC20 install
Hello, I tried to install XP SP3 (also tried XP SP2) on a new VM (IDE, 1GB RAM, VMVGA, more details can be provided if necessary) on Fedora 20 (Packages below), but it hangs on "Installing Windows/Installing Devices". Was reproduceable 2 times. Anyone has similar problems? Looks to me like a regression problem. Thank you. Ciao, Gerhard Details: qemu-kvm-1.6.1-3.fc20.x86_64 kernel: 3.13.6-200.fc20.x86_64 seabios-bin-1.7.3.1-1.fc20.noarch Hardware: Intel
Re: [Qemu-devel] Compile error on FC17
On 10.03.2013 18:04, Peter Maydell wrote:
Oh, right. Tracing functions moved from trace.h to the files in the
trace/ subdirectory. This means that if you didn't do a make clean or
distclean before doing the git update then the new makefile knows
nothing about the old trace.h file and so won't delete it, but the
compiler may still pull it in anyhow. However this happened a long
time back which is why I didn't mention it as a possibility (it was
discussed on the list at the time as a number of people including me
ran into it). If you remove all the files: trace.c trace.h
trace.c-timestamp trace.h-timestamp this should resolve the problem.
This is an example of a longstanding problem we have, where the
makefile's dependency rules aren't able to cope with changes to the
project source file structure, and so clean, distclean and incremental
build sometimes breaks across a git update. I think this is pretty
intractable as a problem to solve; you can mitigate it by doing all
your builds in a build directory rather than in the source tree
itself, since then you can always just delete the whole build tree to
get a definite from-scratch build.
rm -f trace.c trace.h libcacard/trace.c
find . -name \*-timestamp -exec rm -f {} \;
make distclean
make clean
./configure --target-list=x86_64-softmmu
# No files found
find . -name \*-timestamp
# No files found
find . -name trace.c
# Under git version control:
# ./include/trace.h
find . -name trace.h
=> Worked well
But shouldn't "make distclean" do the job correctly (even with a changed
directory structure, at least for some time)?
Ciao,
Gerhard
Re: [Qemu-devel] Compile error on FC17
On 10.03.2013 14:20, Peter Maydell wrote: On 10 March 2013 20:28, Gerhard Wiesinger wrote: Hello, qemu is currently not compile clean: CC util/hbitmap.o util/hbitmap.c: In function ‘hbitmap_iter_skip_words’: util/hbitmap.c:138:5: error: implicit declaration of function ‘trace_hbitmap_iter_skip_words’ [-Werror=implicit-function-declaration] These are all functions which are autogenerated from trace-events into trace/generated-tracers.h (and my git tree has them correctly autogenerated and qemu builds). I suspect (a) our dependency rules for these still aren't right (b) you can fix this with a make clean or distclean or failing everything else by completely nuking the tree and starting from scratch. Hello Peter, Tried make clean and make distclean already before I reported the issue. If I'm suppressing "warning as errors" I'm still getting errors: hw/usb/hcd-xhci.c: In function ‘xhci_set_ep_dequeue’: hw/usb/hcd-xhci.c:1471:5: error: too many arguments to function ‘trace_usb_xhci_ep_set_dequeue’ In file included from hw/usb/hcd-xhci.c:27:0: ./trace.h:1052:58: note: declared here hw/usb/hcd-xhci.c: In function ‘xhci_fire_ctl_transfer’: hw/usb/hcd-xhci.c:1742:5: error: too many arguments to function ‘trace_usb_xhci_xfer_start’ In file included from hw/usb/hcd-xhci.c:27:0: ./trace.h:1068:58: note: declared here hw/usb/hcd-xhci.c: In function ‘xhci_fire_transfer’: hw/usb/hcd-xhci.c:1874:5: error: too many arguments to function ‘trace_usb_xhci_xfer_start’ In file included from hw/usb/hcd-xhci.c:27:0: ./trace.h:1068:58: note: declared here hw/usb/hcd-xhci.c: In function ‘xhci_kick_ep’: hw/usb/hcd-xhci.c:1889:5: error: too many arguments to function ‘trace_usb_xhci_ep_kick’ In file included from hw/usb/hcd-xhci.c:27:0: ./trace.h:1056:58: note: declared here make: *** [hw/usb/hcd-xhci.o] Error 1 make: *** Waiting for unfinished jobs BTW: Isn't a new issue (around 2 month) but was very busy. Ciao, Gerhard
[Qemu-devel] Compile error on FC17
Hello, qemu is currently not compile clean: CC util/hbitmap.o util/hbitmap.c: In function ‘hbitmap_iter_skip_words’: util/hbitmap.c:138:5: error: implicit declaration of function ‘trace_hbitmap_iter_skip_words’ [-Werror=implicit-function-declaration] util/hbitmap.c:138:5: error: nested extern declaration of ‘trace_hbitmap_iter_skip_words’ [-Werror=nested-externs] util/hbitmap.c: In function ‘hbitmap_set’: util/hbitmap.c:271:5: error: implicit declaration of function ‘trace_hbitmap_set’ [-Werror=implicit-function-declaration] util/hbitmap.c:271:5: error: nested extern declaration of ‘trace_hbitmap_set’ [-Werror=nested-externs] util/hbitmap.c: In function ‘hbitmap_reset’: util/hbitmap.c:351:5: error: implicit declaration of function ‘trace_hbitmap_reset’ [-Werror=implicit-function-declaration] util/hbitmap.c:351:5: error: nested extern declaration of ‘trace_hbitmap_reset’ [-Werror=nested-externs] cc1: all warnings being treated as errors make: *** [util/hbitmap.o] Error 1 gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) Ciao, Gerhard
[Qemu-devel] QXL stands for?
Hello, Didn't find it. For what does QXL stand for? Thanx. Ciao, Gerhard
Re: [Qemu-devel] [ANNOUNCE] QEMU 1.3.0 release
On 07.12.2012 08:37, Markus Armbruster wrote: Gerhard Wiesinger writes: On 03.12.2012 21:51, Anthony Liguori wrote: Hi, Major features include: - After nearly 6 years of work, all remaining differences between the qemu-kvm.git and qemu.git have been merged into qemu.git How is qemu-kvm enabled? --enable-kvm ? Yes. Is there a runtime only command line switch also available? I didn't get that. Is it possible to have only one binary built and switch between qemu and qemu-kvm by specifying a command line option? Another possibility might be when binary is name qemu-kvm KVM is enabled otherwise not- Therefore 2 different binary builds between qemu and qemu-kvm aren't necessary. Ciao, Gerhard
Re: [Qemu-devel] [ANNOUNCE] QEMU 1.3.0 release
On 03.12.2012 21:51, Anthony Liguori wrote: Hi, Major features include: - After nearly 6 years of work, all remaining differences between the qemu-kvm.git and qemu.git have been merged into qemu.git How is qemu-kvm enabled? --enable-kvm ? Is there a runtime only command line switch also available? Thank you. Ciao, Gerhard
Re: [Qemu-devel] DOS boot problem with LSI 53C895A SCSI controller and LSI option ROM
On 12.11.2012 09:26, Paolo Bonzini wrote:
Il 10/11/2012 22:39, Gerhard Wiesinger ha scritto:
Hello,
I bisected down a DOS boot problem with LSI 53C895A SCSI controller and
LSI option ROM to the following commit:
e93176d55f1eb4be1a366b51afeaf4f4c8c31d75
The emulation is known to be incomplete; the option ROM is not really
supported, just like the support for the LSI controller in SeaBIOS is
not meant for real hardware.
The option ROM worked perfect for legacy before this commit for years.
But if this is a regression, I can look at it. Problem is, I don't have
the option ROM and I don't think I can obtain one legally. Please
provide at least a trace of the SCSI commands that are sent.
Yes, it is a regression problem.
You can download the option ROM from the LSI homepage:
http://www.lsi.com/support/Pages/Download-Results.aspx?productcode=P00536&assettype=0&component=Storage%20Component&productfamily=0&productname=LSI53C895A
http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/lsi_bios.zip
http://www.lsi.com/downloads/Public/SCSI%20HBAs/SCSI%20HBAs%20Common%20Files/lsi_bios.zip
http://www.lsi.com/downloads/Public/SCSI%20ICs%20and%20Expanders/SCSI%20ICs%20and%20Expanders%20Common%20Files/lsi_bios.zip
http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/lsi_bios.zip
Trace will follow (currently very busy). Best solution to turn it on?
BTW: Nearly all KVM coredumps aren't valid anymore and have only a
garbage stack trace. Any ideas?
It seems strange that this would be limited to KVM. What about other
programs? Or try --disable-pie.
Looks like a general problem on the FC17 machine with latest updates.
Was ok 11 days ago on FC17. program below cores, but also no valid core
dump. Also further information below.
Doesn't look like PIE is active.
Any further hints?
Ciao,
Gerhard
coredump.c:
int main(int argc, char* argv[])
{
char* p = 0;
*p = 0;
return 0;
}
gcc -g coredump.c -o a.out
eu-readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Ident Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: AMD x86-64
Version: 1 (current)
Entry point address: 0x400390
Start of program headers: 64 (bytes into file)
Start of section headers: 3032 (bytes into file)
Flags:
Size of this header: 64 (bytes)
Size of program header entries:56 (bytes)
Number of program headers entries: 8
Size of section header entries:64 (bytes)
Number of section headers entries: 35
Section header string table index: 32
gdb -c core.5671
GNU gdb (GDB) Fedora (7.4.50.20120120-52.fc17)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Missing separate debuginfo for the main executable file
Try: yum --disablerepo='*' --enablerepo='*-debug*' install
/usr/lib/debug/.build-id/ff/36de4d6ecfe0c5b80cbc805916d9acc829619e
[New LWP 5671]
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x004004b3 in ?? ()
(gdb) ba
#0 0x004004b3 in ?? ()
#1 0x in ?? ()
[Qemu-devel] LSI boot hangs
Hello, I'm having a boot hanger with LSI 53C895 adapter with latest qemu (not KVM): hangs in "Searching bootorder for: /pci@i0cf8/*@3/*@0/*@0,0" b90600eed3c0efe5f3260853c873caf51c0677b1 is the first bad commit commit b90600eed3c0efe5f3260853c873caf51c0677b1 Author: Avi Kivity Date: Wed Oct 3 16:42:37 2012 +0200 dma: make dma access its own address space Instead of accessing the cpu address space, use an address space configured by the caller. Eventually all dma functionality will be folded into AddressSpace, but we have to start from something. Reviewed-by: Anthony Liguori Signed-off-by: Avi Kivity :100644 100644 433d8b21b344d7eaa8ffee840d2bc62eefb269fc 3f09dcb072c794d09a4dd0ce753307f121f67609 M dma-helpers.c :100644 100644 1a33603f2260cd2bbc5224790816c8fb037959e4 1bd6f4a65154d1bdcf5bd45cc8a797c89b6c2ca5 M dma.h :04 04 2690964eeda924b5738538e6725ac35a91ac56f7 07577f817d21a21d17645bda96c40b73fbccef87 M hw Any ideas how to fix it? Thank you. Ciao, Gerhard
[Qemu-devel] DOS boot problem with LSI 53C895A SCSI controller and LSI option ROM
Hello, I bisected down a DOS boot problem with LSI 53C895A SCSI controller and LSI option ROM to the following commit: e93176d55f1eb4be1a366b51afeaf4f4c8c31d75 Core dumps aren't valid. BTW: Nearly all KVM coredumps aren't valid anymore and have only a garbage stack trace. Any ideas? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ e93176d55f1eb4be1a366b51afeaf4f4c8c31d75 is the first bad commit commit e93176d55f1eb4be1a366b51afeaf4f4c8c31d75 Author: Paolo Bonzini Date: Wed Sep 5 18:00:57 2012 +0200 scsi-disk: use scsi_data_cdb_length This simplifies and unifies the parsing of READ, WRITE and WRITE SAME commands. Signed-off-by: Paolo Bonzini :04 04 2b900c9e27f8e5d6c402cbcfefab41c3ce7e5dc2 93d7ff199256b55e0bef3a7a9c31ce786b814454 M hw
Re: [Qemu-devel] [PATCH] block.c, block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION
On 10.11.2012 09:55, Paolo Bonzini wrote:
Il 10/11/2012 09:30, Gerhard Wiesinger ha scritto:
2.) Added debug code to block.c and to block/vmdk.c to verify
correctness
Same here. Also, please use the tracing infrastructure---a lot of the
debug
messages you're adding, though not all, are in fact already available
(not
saying the others aren't useful!)
Any chance that the patch with debug code only (after some cleaning)
would be accepted (other modules do debug logging, too)?
I don't like to do useless work.
Tracing infrastructure is quite limited to function calls only (as far
as I saw).
No, tracing infrastructure uses function calls for tracing (messages go
into trace-events) but you can apply it to everything you want. Use the
stderr backend to debug it.
Tracing is a good thing for normal behavior but the major limitation is
that a function call must be involved. But for deep debugging one needs
a lot of more messages than function calls are available.
Of course every DPRINTF line could be made in a function call but IHMO
this introduces unnecessary overhead in performance.
So how to proceed further, some options:
1.) Add additional function calls for each DPRINTF statement?
2.) Add just plain DPRINTF statements?
3.) Or a mixture of both: on function call boundaries use Tracing, in
function debug info use DPRINTF?
4.) Refactor code that always function calls are involved?
Example:
static void traceing_func(int mul)
{
// Do nothing here
}
// Just some dummy useless function doing illustration
static int addandmultiply(int arg1, int arg2)
{
int mul = 0;
int sum = arg1 + arg2;
DPRINTF("", arg1, arg2); // this one can be handled by tracing
infrastructure
DPRINTF("", sum); // this one can't be done with tracing
if (sum == 0)
{
DPRINTF("sum=0"); // this one can't be done with tracing
return;
}
mul = arg1 * arg2;
DPRINTF(, mul); // this one can't be done with tracing (except
with a introduced tracing function)
traceing_func(mul); // Introduce tracing function, performance penalty
return sum + mul;
}
So how to proceed further?
Ciao,
Gerhard
Re: [Qemu-devel] [PATCH] block.c, block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION
On 09.11.2012 09:26, Paolo Bonzini wrote: Il 08/11/2012 20:05, Gerhard Wiesinger ha scritto: Fixed a MAJOR BUG in VMDK files on file boundaries on reads and ALSO ON WRITES WHICH MIGHT CORRUPT THE IMAGE AND DATA!! Triggered for example with the following VMDK file (partly listed): # Extent description RW 4193792 FLAT "XP-W1-f001.vmdk" 0 RW 2097664 FLAT "XP-W1-f002.vmdk" 0 RW 4193792 FLAT "XP-W1-f003.vmdk" 0 RW 512 FLAT "XP-W1-f004.vmdk" 0 RW 4193792 FLAT "XP-W1-f005.vmdk" 0 RW 2097664 FLAT "XP-W1-f006.vmdk" 0 RW 4193792 FLAT "XP-W1-f007.vmdk" 0 RW 512 FLAT "XP-W1-f008.vmdk" 0 Patch includes: 1.) Patch fixes wrong calculation on extent boundaries. Especially it fixes the relativeness of the sector number to the current extent. Please just fix _this_ part. Everything else is not necessary for example for distributions to fix this. It's an important bug, so we actually want to make that as simple as this. Sent. 2.) Added debug code to block.c and to block/vmdk.c to verify correctness Same here. Also, please use the tracing infrastructure---a lot of the debug messages you're adding, though not all, are in fact already available (not saying the others aren't useful!) Any chance that the patch with debug code only (after some cleaning) would be accepted (other modules do debug logging, too)? I don't like to do useless work. Tracing infrastructure is quite limited to function calls only (as far as I saw). 3.) Also optimized code which avoids multiplication and uses shifts. The compiler can do this for you. Most importantly, making it more complex for reviewers to find only the "interesting" part. Please check that the attached patch still works. Made some tests and gcc is really clever in optimizing. Even other multipliers (513, 514, ...) than 512 will be optimized to shifts and adds until a limit of 512+8 (I think it was that) was reached. :-) Bugfix only resent. Ciao, Gerhard
[Qemu-devel] [PATCH] block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION
Fixed a MAJOR BUG in VMDK files on file boundaries on reads
and ALSO ON WRITES WHICH MIGHT CORRUPT THE IMAGE AND DATA!!
Triggered for example with the following VMDK file (partly listed):
# Extent description
RW 4193792 FLAT "XP-W1-f001.vmdk" 0
RW 2097664 FLAT "XP-W1-f002.vmdk" 0
RW 4193792 FLAT "XP-W1-f003.vmdk" 0
RW 512 FLAT "XP-W1-f004.vmdk" 0
RW 4193792 FLAT "XP-W1-f005.vmdk" 0
RW 2097664 FLAT "XP-W1-f006.vmdk" 0
RW 4193792 FLAT "XP-W1-f007.vmdk" 0
RW 512 FLAT "XP-W1-f008.vmdk" 0
Patch includes:
1.) Patch fixes wrong calculation on extent boundaries. Especially it fixes the
relativeness of the sector number to the current extent.
Verfied correctness with:
1.) Converted either with Virtualbox to VDI and then with qemu-img and then
with qemu-img only
VBoxManage clonehd --format vdi /VM/XP-W/new/XP-W1.vmdk
~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
./qemu-img convert -O raw ~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
/root/QEMU/VM-XP-W1/XP-W1-via-VBOX.img
md5sum /root/QEMU/VM-XP-W/XP-W1-direct.img
md5sum /root/QEMU/VM-XP-W/XP-W1-via-VBOX.img
=> same MD5 hash
2.) Verified debug log files
3.) Run Windows XP successfully
4.) chkdsk run successfully without any errors
Signed-off-by: Gerhard Wiesinger
---
block/vmdk.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 1a80e5a..51398c0 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1092,6 +1092,7 @@ static int vmdk_read(BlockDriverState *bs, int64_t
sector_num,
BDRVVmdkState *s = bs->opaque;
int ret;
uint64_t n, index_in_cluster;
+uint64_t extent_begin_sector, extent_relative_sector_num;
VmdkExtent *extent = NULL;
uint64_t cluster_offset;
@@ -1103,7 +1104,9 @@ static int vmdk_read(BlockDriverState *bs, int64_t
sector_num,
ret = get_cluster_offset(
bs, extent, NULL,
sector_num << 9, 0, &cluster_offset);
-index_in_cluster = sector_num % extent->cluster_sectors;
+extent_begin_sector = extent->end_sector - extent->sectors;
+extent_relative_sector_num = sector_num - extent_begin_sector;
+index_in_cluster = extent_relative_sector_num %
extent->cluster_sectors;
n = extent->cluster_sectors - index_in_cluster;
if (n > nb_sectors) {
n = nb_sectors;
@@ -1154,6 +1157,7 @@ static int vmdk_write(BlockDriverState *bs, int64_t
sector_num,
VmdkExtent *extent = NULL;
int n, ret;
int64_t index_in_cluster;
+uint64_t extent_begin_sector, extent_relative_sector_num;
uint64_t cluster_offset;
VmdkMetaData m_data;
@@ -1196,7 +1200,9 @@ static int vmdk_write(BlockDriverState *bs, int64_t
sector_num,
if (ret) {
return -EINVAL;
}
-index_in_cluster = sector_num % extent->cluster_sectors;
+extent_begin_sector = extent->end_sector - extent->sectors;
+extent_relative_sector_num = sector_num - extent_begin_sector;
+index_in_cluster = extent_relative_sector_num %
extent->cluster_sectors;
n = extent->cluster_sectors - index_in_cluster;
if (n > nb_sectors) {
n = nb_sectors;
--
1.7.11.7
Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
On 10.11.2012 00:52, Peter Maydell wrote: On 10 November 2012 00:45, Marek Vasut wrote: Gerd Hoffmann wrote: Question is just whenever we'll go silently fixup stuff in console.c or use assert()s to enforce callers getting this correct. I'd tend to use assert() as vmware-vga passing bogous stuff there IMHO indicates there is a bug in vmware-vga. Or rather some revisions of the guest X driver. If qemu's vmware-vga is blithely trusting what the guest driver hands it then that is itself a bug... To answer Gerd's question, I think I'd go for clip rather than assert (especially at this point in the release cycle), though I don't feel very strongly about it. I'd go for clipping rather than asserting too (no crash) in all layers as a defensive approach (console.c/vnc.c). Additionally logging that condition would be helpful that the arising bug (which occurred several times with a lot of unapplied fixes) can be detected by users easily and fixed accordingly. Ciao, Gerhard
Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
On 08.11.2012 22:07, Gerd Hoffmann wrote: Hi, I think this is fixing this at the wrong level. Either we should require that drivers (in this case vmware_vga.c) must not call dpy_gfx_update() with out of range values, or we should do the clipping in the console.c layer, but I don't think requiring every UI backend to clip is the right thing. Anthony? Agree. IMHO vmware_vga.c is at fault here and should be fixed. We can add some asserts to console.[ch] to enforce this ... Regarding fail safe programming I think it should be fixed/handled in both modules: vmware_vga.c should not trigger wrong values but also other modules should verify or even correct there input parameters. (think of situations where bits might not be accurate due to CPU bugs or even QEMU/KVM in aerospace where bits fall to other states due to high energy cosmic ray). Best solution is IHMO for vnc.c: 1.) Log the problem (that other modules can be fixed, too). 2.) Fix parameters (so that program doesn't crash) In mission critical software application like aerospace, airplanes, cars, etc. (e.g. where people might get unhealthy) handling such situations where input parameters aren't as expected is a must. See: https://en.wikipedia.org/wiki/Fail-safe https://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electronics https://en.wikipedia.org/wiki/Radiation_hardening Precondition: https://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Design_by_Contract Ciao, Gerhard
Re: [Qemu-devel] [PATCH] block.c, block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION
Hello,
It was created with VMWare Server 2.0.x or maybe even with 1.x. under Linux.
Ciao,
Gerhard
On 09.11.2012 06:12, Fam Zheng wrote:
Yes, I can confirm the presence of this bug and this is a valid fix.
May I ask where is this kind of vmdk from? Because regularly we see
extents in identical size.
---
Best regards!
Fam Zheng
On Fri, Nov 9, 2012 at 3:05 AM, Gerhard Wiesinger wrote:
Fixed a MAJOR BUG in VMDK files on file boundaries on reads
and ALSO ON WRITES WHICH MIGHT CORRUPT THE IMAGE AND DATA!!
Triggered for example with the following VMDK file (partly listed):
# Extent description
RW 4193792 FLAT "XP-W1-f001.vmdk" 0
RW 2097664 FLAT "XP-W1-f002.vmdk" 0
RW 4193792 FLAT "XP-W1-f003.vmdk" 0
RW 512 FLAT "XP-W1-f004.vmdk" 0
RW 4193792 FLAT "XP-W1-f005.vmdk" 0
RW 2097664 FLAT "XP-W1-f006.vmdk" 0
RW 4193792 FLAT "XP-W1-f007.vmdk" 0
RW 512 FLAT "XP-W1-f008.vmdk" 0
Patch includes:
1.) Patch fixes wrong calculation on extent boundaries. Especially it fixes
the relativeness of the sector number to the current extent.
2.) Added debug code to block.c and to block/vmdk.c to verify correctness
3.) Also optimized code which avoids multiplication and uses shifts.
Verfied correctness with:
1.) Converted either with Virtualbox to VDI and then with qemu-img and then
with qemu-img only
VBoxManage clonehd --format vdi /VM/XP-W/new/XP-W1.vmdk
~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
./qemu-img convert -O raw ~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
/root/QEMU/VM-XP-W1/XP-W1-via-VBOX.img
md5sum /root/QEMU/VM-XP-W/XP-W1-direct.img
md5sum /root/QEMU/VM-XP-W/XP-W1-via-VBOX.img
=> same MD5 hash
2.) Verified debug log files
3.) Run Windows XP successfully
4.) chkdsk run successfully without any errors
Signed-off-by: Gerhard Wiesinger
---
block.c | 50 +++
block/vmdk.c | 129
++-
2 files changed, 170 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index da1fdca..69259f2 100644
--- a/block.c
+++ b/block.c
@@ -49,6 +49,12 @@
#include
#endif
+#if 0
+ #define DEBUG_BLOCK
+#endif
+
+#define DEBUG_BLOCK_PREFIX "BLOCK: "
+
#define NOT_DONE 0x7fff /* used while emulated sync operation in
progress */
typedef enum {
@@ -789,6 +795,18 @@ int bdrv_open(BlockDriverState *bs, const char
*filename, int flags,
int ret;
char tmp_filename[PATH_MAX];
+#ifdef DEBUG_BLOCK
+const char *format = "(nil)";
+if (drv) {
+format = drv->format_name;
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_open: filename=%s, BlockDriver=%p, format=%s\n",
+ filename, drv, format
+ );
+#endif
+
if (flags & BDRV_O_SNAPSHOT) {
BlockDriverState *bs1;
int64_t total_size;
@@ -2004,6 +2022,22 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t
sector_num, uint8_t *buf,
int bdrv_read(BlockDriverState *bs, int64_t sector_num,
uint8_t *buf, int nb_sectors)
{
+#ifdef DEBUG_BLOCK
+BlockDriver *drv = bs->drv;
+const char *format_name = "(nil)";
+if (drv) {
+if (drv->format_name) {
+format_name = drv->format_name;
+}
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_read: driver=%s, filename=%s, sector_num=%" PRId64
+ ", nb_sectors=%i\n",
+ format_name, bs->filename, sector_num, nb_sectors
+ );
+#endif
+
return bdrv_rw_co(bs, sector_num, buf, nb_sectors, false);
}
@@ -2060,6 +2094,22 @@ static void set_dirty_bitmap(BlockDriverState *bs,
int64_t sector_num,
int bdrv_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
+#ifdef DEBUG_BLOCK
+BlockDriver *drv = bs->drv;
+const char *format_name = "(nil)";
+if (drv) {
+if (drv->format_name) {
+format_name = drv->format_name;
+}
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_write: driver=%s, filename=%s, sector_num=%" PRId64
+ ", nb_sectors=%i\n",
+ format_name, bs->filename, sector_num, nb_sectors
+ );
+#endif
+
return bdrv_rw_co(bs, sector_num, (uint8_t *)buf, nb_sectors, true);
}
diff --git a/block/vmdk.c b/block/vmdk.c
index 1a80e5a..92ab92c 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -29,6 +29,15 @@
#include "migration.h"
#include
+#if 0
+#define DEBUG_VMDK
+#endif
+
+#define DEBUG_VMDK_PREFIX "VMDK: "
+#define DEBUG_VMDK_SEPARATOR \
+"" \
+""
+
#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
#define VMDK4_MAGIC (('K' << 24) |
[Qemu-devel] [PATCH] block.c, block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION
Fixed a MAJOR BUG in VMDK files on file boundaries on reads
and ALSO ON WRITES WHICH MIGHT CORRUPT THE IMAGE AND DATA!!
Triggered for example with the following VMDK file (partly listed):
# Extent description
RW 4193792 FLAT "XP-W1-f001.vmdk" 0
RW 2097664 FLAT "XP-W1-f002.vmdk" 0
RW 4193792 FLAT "XP-W1-f003.vmdk" 0
RW 512 FLAT "XP-W1-f004.vmdk" 0
RW 4193792 FLAT "XP-W1-f005.vmdk" 0
RW 2097664 FLAT "XP-W1-f006.vmdk" 0
RW 4193792 FLAT "XP-W1-f007.vmdk" 0
RW 512 FLAT "XP-W1-f008.vmdk" 0
Patch includes:
1.) Patch fixes wrong calculation on extent boundaries. Especially it fixes the
relativeness of the sector number to the current extent.
2.) Added debug code to block.c and to block/vmdk.c to verify correctness
3.) Also optimized code which avoids multiplication and uses shifts.
Verfied correctness with:
1.) Converted either with Virtualbox to VDI and then with qemu-img and then
with qemu-img only
VBoxManage clonehd --format vdi /VM/XP-W/new/XP-W1.vmdk
~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
./qemu-img convert -O raw ~/.VirtualBox/Harddisks/XP-W1-new-test.vdi
/root/QEMU/VM-XP-W1/XP-W1-via-VBOX.img
md5sum /root/QEMU/VM-XP-W/XP-W1-direct.img
md5sum /root/QEMU/VM-XP-W/XP-W1-via-VBOX.img
=> same MD5 hash
2.) Verified debug log files
3.) Run Windows XP successfully
4.) chkdsk run successfully without any errors
Signed-off-by: Gerhard Wiesinger
---
block.c | 50 +++
block/vmdk.c | 129 ++-
2 files changed, 170 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index da1fdca..69259f2 100644
--- a/block.c
+++ b/block.c
@@ -49,6 +49,12 @@
#include
#endif
+#if 0
+ #define DEBUG_BLOCK
+#endif
+
+#define DEBUG_BLOCK_PREFIX "BLOCK: "
+
#define NOT_DONE 0x7fff /* used while emulated sync operation in progress
*/
typedef enum {
@@ -789,6 +795,18 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
int ret;
char tmp_filename[PATH_MAX];
+#ifdef DEBUG_BLOCK
+const char *format = "(nil)";
+if (drv) {
+format = drv->format_name;
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_open: filename=%s, BlockDriver=%p, format=%s\n",
+ filename, drv, format
+ );
+#endif
+
if (flags & BDRV_O_SNAPSHOT) {
BlockDriverState *bs1;
int64_t total_size;
@@ -2004,6 +2022,22 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t
sector_num, uint8_t *buf,
int bdrv_read(BlockDriverState *bs, int64_t sector_num,
uint8_t *buf, int nb_sectors)
{
+#ifdef DEBUG_BLOCK
+BlockDriver *drv = bs->drv;
+const char *format_name = "(nil)";
+if (drv) {
+if (drv->format_name) {
+format_name = drv->format_name;
+}
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_read: driver=%s, filename=%s, sector_num=%" PRId64
+ ", nb_sectors=%i\n",
+ format_name, bs->filename, sector_num, nb_sectors
+ );
+#endif
+
return bdrv_rw_co(bs, sector_num, buf, nb_sectors, false);
}
@@ -2060,6 +2094,22 @@ static void set_dirty_bitmap(BlockDriverState *bs,
int64_t sector_num,
int bdrv_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
+#ifdef DEBUG_BLOCK
+BlockDriver *drv = bs->drv;
+const char *format_name = "(nil)";
+if (drv) {
+if (drv->format_name) {
+format_name = drv->format_name;
+}
+}
+
+printf(DEBUG_BLOCK
+ "bdrv_write: driver=%s, filename=%s, sector_num=%" PRId64
+ ", nb_sectors=%i\n",
+ format_name, bs->filename, sector_num, nb_sectors
+ );
+#endif
+
return bdrv_rw_co(bs, sector_num, (uint8_t *)buf, nb_sectors, true);
}
diff --git a/block/vmdk.c b/block/vmdk.c
index 1a80e5a..92ab92c 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -29,6 +29,15 @@
#include "migration.h"
#include
+#if 0
+#define DEBUG_VMDK
+#endif
+
+#define DEBUG_VMDK_PREFIX "VMDK: "
+#define DEBUG_VMDK_SEPARATOR \
+"" \
+""
+
#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
#define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
#define VMDK4_COMPRESSION_DEFLATE 1
@@ -377,6 +386,16 @@ static VmdkExtent *vmdk_add_extent(BlockDriverState *bs,
VmdkExtent *extent;
BDRVVmdkState *s = bs->opaque;
+#ifdef DEBUG_VMDK
+printf(DEBUG_VMDK_PREFIX
+ "vmdk_add_extent: flat=%i, sectors=%" PRId64
+ ", l1_backup_offset=%&qu
Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
Yet another ping. Ciao, Gerhard On 04.11.2012 11:28, Gerhard Wiesinger wrote: Ping? On 01.11.2012 21:06, Gerhard Wiesinger wrote: Fix crash with VNC under NT 4.0 and VMWare VGA and window which is outside of the visible area. Backtrace: #0 set_bit (addr=, nr=-3) at ./bitops.h:122 #1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at ui/vnc.c:452 #2 0x7f1ce057e2ec in dpy_update (s=0x7f1ce1c8c880, h=16, w=66, y=145, x=-57) at ./console.h:242 #3 vmsvga_update_rect (h=16, w=66, y=145, x=-57, s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:324 #4 vmsvga_update_rect_flush (s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:357 #5 vmsvga_update_display (opaque=0x7f1ce1cb3dd0) at hw/vmware_vga.c:960 #6 0x7f1ce05f0b37 in vnc_refresh (opaque=0x7f1cd8526010) at ui/vnc.c:2590 #7 0x7f1ce05c002b in qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:392 #8 qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:373 #9 0x7f1ce05c028d in qemu_run_all_timers () at qemu-timer.c:449 #10 0x7f1ce058f2ee in main_loop_wait (nonblocking=out>) at main-loop.c:502 #11 0x7f1ce047acb3 in main_loop () at vl.c:1655 #12 main (argc=, argv=, envp=out>) at vl.c:3826 Signed-off-by: Gerhard Wiesinger --- ui/vnc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/ui/vnc.c b/ui/vnc.c index 7c120e6..ae6d819 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -453,6 +453,11 @@ static void vnc_dpy_update(DisplayState *ds, int x, int y, int w, int h) w = MIN(x + w, width) - x; h = MIN(h, height); +x = MAX(x, 0); +y = MAX(y, 0); +w = MAX(w, 0); +h = MAX(h, 0); + for (; y < h; y++) for (i = 0; i < w; i += 16) set_bit((x + i) / 16, s->dirty[y]);
[Qemu-devel] Crash on Windows XP startup
Hello, I bisected down a Windows XP startup crash to the following commit: 0b57e287138728f72d88b06e69b970c5d745c44a is the first bad commit commit 0b57e287138728f72d88b06e69b970c5d745c44a Author: David Gibson Date: Mon Sep 10 12:30:57 2012 +1000 Reproduceable on qemu HEAD and by commenting out the refactored patch into a function. How to proceed? Ciao, Gerhard diff --git a/exec.c b/exec.c index af94f9c..a937882 100644 --- a/exec.c +++ b/exec.c @@ -3501,7 +3501,7 @@ void cpu_physical_memory_write_rom(hwaddr addr, /* ROM/RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); -invalidate_and_set_dirty(addr1, l); +//invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } len -= l;
Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
Ping? On 01.11.2012 21:06, Gerhard Wiesinger wrote: Fix crash with VNC under NT 4.0 and VMWare VGA and window which is outside of the visible area. Backtrace: #0 set_bit (addr=, nr=-3) at ./bitops.h:122 #1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at ui/vnc.c:452 #2 0x7f1ce057e2ec in dpy_update (s=0x7f1ce1c8c880, h=16, w=66, y=145, x=-57) at ./console.h:242 #3 vmsvga_update_rect (h=16, w=66, y=145, x=-57, s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:324 #4 vmsvga_update_rect_flush (s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:357 #5 vmsvga_update_display (opaque=0x7f1ce1cb3dd0) at hw/vmware_vga.c:960 #6 0x7f1ce05f0b37 in vnc_refresh (opaque=0x7f1cd8526010) at ui/vnc.c:2590 #7 0x7f1ce05c002b in qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:392 #8 qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:373 #9 0x7f1ce05c028d in qemu_run_all_timers () at qemu-timer.c:449 #10 0x7f1ce058f2ee in main_loop_wait (nonblocking=) at main-loop.c:502 #11 0x7f1ce047acb3 in main_loop () at vl.c:1655 #12 main (argc=, argv=, envp=out>) at vl.c:3826 Signed-off-by: Gerhard Wiesinger --- ui/vnc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/ui/vnc.c b/ui/vnc.c index 7c120e6..ae6d819 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -453,6 +453,11 @@ static void vnc_dpy_update(DisplayState *ds, int x, int y, int w, int h) w = MIN(x + w, width) - x; h = MIN(h, height); +x = MAX(x, 0); +y = MAX(y, 0); +w = MAX(w, 0); +h = MAX(h, 0); + for (; y < h; y++) for (i = 0; i < w; i += 16) set_bit((x + i) / 16, s->dirty[y]);
[Qemu-devel] XP install cores with SCSI LSI 53C895A disks - follow up
Hello, Clean XP install cores with SCSI LSI 53C89A disk when copying files. Isn't on the same file, so looks like a timing problem. Reproduceable. Driver used is sym_hi. Details are below. See also: https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg00523.html Looks like problem is from Paolo's commit: 2f0772c5b4818d4b2078be9dace0036d1030faee qemu-system-x86_64: hw/lsi53c895a.c:351: lsi_soft_reset: Assertion `((&s->queue)->tqh_first == ((void *)0))' failed. So SCSI queue isn't empty (was an assumption and asserted), so qdev_reset_all(&s->dev.qdev); might not work or some other timing related issues. Any ideas to solve? Reproduceable? I'm using BIOS from SEABIOS. Thank you. Ciao, Gerhard Image created with: qemu-img create -f qcow2 XP-TEST.qcow2 10G qemu-kvm: 4d9367b76f71c6d938cf8201392abe4bfb1136cb /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -device nec-usb-xhci,id=usb0 -drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0 -drive if=ide,index=3,media=cdrom,file=ISO/XP.iso -boot order=dac,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device rtl8139,mac=00:02:44:92:87:6a,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0
Re: [Qemu-devel] Compile error
On 01.11.2012 21:58, Anthony Liguori wrote: What platform is this breaking on? Can you point me to the buildbot failure? Fedora 17, x64: 3.6.3-1.fc17.x86_64 gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) E.g. here: http://www.kraxel.org/bb/builders/fedora-default/builds/888/steps/compile/logs/stdio Ciao, Gerhard
Re: [Qemu-devel] Compile error
Hello, Yes, compiles when warnings are not treated as errors. But do we want to be only compile clean when we suppress such warnings? Also ./configure with plattform should be enough. Ciao, Gerhard On 01.11.2012 21:13, Max Filippov wrote: On Thu, Nov 1, 2012 at 11:47 PM, Gerhard Wiesinger wrote: Ping again ... Can you just configure it with --disable-werror ? IIRC it is the default for the released QEMU versions. On 10.10.2012 07:17, Gerhard Wiesinger wrote: Hello, Still not compile clean, also on the build servers. Who is responsible for the fix? Ciao, Gerhard On 16.09.2012 18:25, Gerhard Wiesinger wrote: Hello, qemu is currently not compile clean on Fedora 17: CC fsdev/virtfs-proxy-helper.o fsdev/virtfs-proxy-helper.c: In function ‘setfsugid’: fsdev/virtfs-proxy-helper.c:293:13: error: ignoring return value of ‘setfsgid’, declared with attribute warn_unused_result [-Werror=unused-result] fsdev/virtfs-proxy-helper.c:294:13: error: ignoring return value of ‘setfsuid’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make: *** [fsdev/virtfs-proxy-helper.o] Error 1 gcc --version gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Please fix it.
[Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
Fix crash with VNC under NT 4.0 and VMWare VGA and window which is outside of the visible area. Backtrace: #0 set_bit (addr=, nr=-3) at ./bitops.h:122 #1 vnc_dpy_update (ds=, x=-48, y=145, w=57, h=161) at ui/vnc.c:452 #2 0x7f1ce057e2ec in dpy_update (s=0x7f1ce1c8c880, h=16, w=66, y=145, x=-57) at ./console.h:242 #3 vmsvga_update_rect (h=16, w=66, y=145, x=-57, s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:324 #4 vmsvga_update_rect_flush (s=0x7f1ce1cb3dd0) at hw/vmware_vga.c:357 #5 vmsvga_update_display (opaque=0x7f1ce1cb3dd0) at hw/vmware_vga.c:960 #6 0x7f1ce05f0b37 in vnc_refresh (opaque=0x7f1cd8526010) at ui/vnc.c:2590 #7 0x7f1ce05c002b in qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:392 #8 qemu_run_timers (clock=0x7f1ce1c4f910) at qemu-timer.c:373 #9 0x7f1ce05c028d in qemu_run_all_timers () at qemu-timer.c:449 #10 0x7f1ce058f2ee in main_loop_wait (nonblocking=) at main-loop.c:502 #11 0x7f1ce047acb3 in main_loop () at vl.c:1655 #12 main (argc=, argv=, envp=) at vl.c:3826 Signed-off-by: Gerhard Wiesinger --- ui/vnc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/ui/vnc.c b/ui/vnc.c index 7c120e6..ae6d819 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -453,6 +453,11 @@ static void vnc_dpy_update(DisplayState *ds, int x, int y, int w, int h) w = MIN(x + w, width) - x; h = MIN(h, height); +x = MAX(x, 0); +y = MAX(y, 0); +w = MAX(w, 0); +h = MAX(h, 0); + for (; y < h; y++) for (i = 0; i < w; i += 16) set_bit((x + i) / 16, s->dirty[y]); -- 1.7.11.7
Re: [Qemu-devel] Compile error
Ping again ... Ciao, Gerhard On 10.10.2012 07:17, Gerhard Wiesinger wrote: Hello, Still not compile clean, also on the build servers. Who is responsible for the fix? Ciao, Gerhard On 16.09.2012 18:25, Gerhard Wiesinger wrote: Hello, qemu is currently not compile clean on Fedora 17: CC fsdev/virtfs-proxy-helper.o fsdev/virtfs-proxy-helper.c: In function ‘setfsugid’: fsdev/virtfs-proxy-helper.c:293:13: error: ignoring return value of ‘setfsgid’, declared with attribute warn_unused_result [-Werror=unused-result] fsdev/virtfs-proxy-helper.c:294:13: error: ignoring return value of ‘setfsuid’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make: *** [fsdev/virtfs-proxy-helper.o] Error 1 gcc --version gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Please fix it. Ciao, Gerhard
Re: [Qemu-devel] Compile error
Hello, Still not compile clean, also on the build servers. Who is responsible for the fix? Ciao, Gerhard On 16.09.2012 18:25, Gerhard Wiesinger wrote: Hello, qemu is currently not compile clean on Fedora 17: CC fsdev/virtfs-proxy-helper.o fsdev/virtfs-proxy-helper.c: In function ‘setfsugid’: fsdev/virtfs-proxy-helper.c:293:13: error: ignoring return value of ‘setfsgid’, declared with attribute warn_unused_result [-Werror=unused-result] fsdev/virtfs-proxy-helper.c:294:13: error: ignoring return value of ‘setfsuid’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make: *** [fsdev/virtfs-proxy-helper.o] Error 1 gcc --version gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Please fix it. Ciao, Gerhard
[Qemu-devel] Compile error
Hello, qemu is currently not compile clean on Fedora 17: CC fsdev/virtfs-proxy-helper.o fsdev/virtfs-proxy-helper.c: In function ‘setfsugid’: fsdev/virtfs-proxy-helper.c:293:13: error: ignoring return value of ‘setfsgid’, declared with attribute warn_unused_result [-Werror=unused-result] fsdev/virtfs-proxy-helper.c:294:13: error: ignoring return value of ‘setfsuid’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make: *** [fsdev/virtfs-proxy-helper.o] Error 1 gcc --version gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Please fix it. Ciao, Gerhard
Re: [Qemu-devel] [PATCH] hw: Add support for new LSI Logic devices.
On 11.09.2012 19:00, Don Slutz wrote: Add LSI53C1030, SAS1068, SAS1068e. Based on code from "VirtualBox Open Source Edition". Based on QEMU MegaRAID SAS 8708EM2. This is a common VMware disk controller. SEABIOS change for booting is in the works. Tested with Fedora 16, 17. CentoOS 6. Windows 2003R2 and 2008R2. Signed-off-by: Don Slutz Hello Don, Looks great! Will give it a try. BTW: Anyone working on a Buslogic SCSI implementation. Then the list for VMWare is IHMO complete. Ciao, Gerhard
[Qemu-devel] TRIM, UNMAP and QCOW2 release of block information - Thin provisioning
Hello, As far as I saw QEMU/KVM supports the trim command on IDE/SATA devices and the UNMAP command on SCSI devices/disks (thanks Paolo Bonzini). Will the qcow2 format (or other formats) use this information and also release the blocks for thin provisioning to save disk space on filesystems? VirtualBox also has such a feature in the new beta version: http://www.fb-developers.info/blog/2012/virtualbox-v4-2-is-coming/ Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
[Qemu-devel] Compile errors on latest checkout
Hello, I'm getting the following compile errors: /root/download/qemu/git/qemu/hw/megasas.c: In function ‘megasas_class_init’: /root/download/qemu/git/qemu/hw/megasas.c:2155:14: error: assignment from incompatible pointer type [-Werror] pc->exit = megasas_scsi_uninit; With #define DEBUG_SCSI hw/scsi-disk.c: In function ‘scsi_write_complete’: hw/scsi-disk.c:450:9: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Werror=format] hw/scsi-disk.c: In function ‘scsi_disk_emulate_read_data’: hw/scsi-disk.c:1274:9: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 2 has type ‘int’ [-Werror=format] hw/scsi-disk.c: In function ‘scsi_disk_emulate_write_data’: hw/scsi-disk.c:1452:9: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 2 has type ‘int’ [-Werror=format] hw/scsi-disk.c: In function ‘scsi_new_request’: hw/scsi-disk.c:2091:5: error: format ‘%x’ expects a matching ‘unsigned int’ argument [-Werror=format] hw/scsi-disk.c:2094:25: error: ‘r’ undeclared (first use in this function) hw/scsi-disk.c:2094:25: note: each undeclared identifier is reported only once for each function it appears in Please fix it. gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) Thnx. Ciao, Gerhard
Re: [Qemu-devel] [PATCH 0/7 V6] VMXNET3 paravirtual NIC device implementation
As already pretested this patch I got from Dmitry now I successfully tested it on Fedora 16 and Knoppix 6.7 (retested again successfully). netio performance on localhost (ok): Packet size 1k bytes: 33645 KByte/s Tx, 25279 KByte/s Rx. Packet size 2k bytes: 45884 KByte/s Tx, 24854 KByte/s Rx. Packet size 4k bytes: 80332 KByte/s Tx, 42068 KByte/s Rx. Packet size 8k bytes: 117696 KByte/s Tx, 64489 KByte/s Rx. Packet size 16k bytes: 150418 KByte/s Tx, 100288 KByte/s Rx. Packet size 32k bytes: 182412 KByte/s Tx, 138779 KByte/s Rx. Since hw passed also WHQL tests it is IHMO ready for commit :-) Formal: Tested-by: Gerhard Wiesinger Ciao, Gerhard On 17.04.2012 14:32, Dmitry Fleytman wrote: From: Dmitry Fleytman This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V6: Fixed most of problems pointed out by Michael S. Tsirkin The only issue still open is creation of shared place with generic network structures and functions. Currently all generic network code introduced by VMXNET3 resides in vmxnet_utils.c/h files. It could be moved to some shared location however we believe it is a matter of separate refactoring as there are a lot of copy-pasted definitions in almost every device and code cleanup efforts requred in order to create truly shared codebase. Reported-by: Michael S. Tsirkin Implemented suggestions by Anthony Liguori Reported-by: Anthony Liguori Fixed incorrect checksum caclulation for some packets in SW offloads mode Reported-by: Gerhard Wiesinger Changes in V5: MSI-X save/load implemented in the device instead of pci bus as suggested by Michael S. Tsirkin Reported-by: Michael S. Tsirkin Patches regrouped as suggested by Paolo Bonzini Reported-by: Paolo Bonzini Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (7): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tree Reformatting comments according to checkpatch.pl requirements Adding utility function net_checksum_add_cont() that allows checksum calculation of scattered data with odd chunk sizes Adding utility function iov_net_csum_add() for iovec checksum calculation Adding utility function iov_rebuild() for smart iovec copy Header with various utility functions shared by VMWARE SCSI and network devices Various utility functions used by VMWARE network devices Packet abstraction used by VMWARE network devices VMXNET3 paravirtualized device implementation Device "vmxnet3" added. Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.h|1 + hw/virtio-net.h | 13 +- hw/vmware_utils.h | 126 +++ hw/vmxnet3.c| 2435 +++ hw/vmxnet3.h| 762 +++ hw/vmxnet_debug.h | 121 +++ hw/vmxnet_pkt.c | 776 +++ hw/vmxnet_pkt.h | 311 ++ hw/vmxnet_utils.c | 219 + hw/vmxnet_utils.h | 341 +++ iov.c | 53 + iov.h |6 + net/checksum.c | 13 +- net/checksum.h | 14 +- 16 files changed, 5180 insertions(+), 13 deletions(-) create mode 100644 hw/vmware_utils.h create mode 100644 hw/vmxnet3.c create mode 100644 hw/vmxnet3.h create mode 100644 hw/vmxnet_debug.h create mode 100644 hw/vmxnet_pkt.c create mode 100644 hw/vmxnet_pkt.h create mode 100644 hw/vmxnet_utils.c create mode 100644 hw/vmxnet_utils.h
Re: [Qemu-devel] [PATCH 0/3] switch to seavgabios
Negative also here: Don't see anything on screen on startup... From log, latest qemu-kvm git version: Running option rom at c180:3d4e Running option rom at c180:3da2 Running option rom at c180:3df6 Running option rom at c580:0003 qemu-system-x86_64: /root/download/qemu/git/qemu-kvm/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. Startup is done with the following command: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=1.img,media=disk,if=scsi,bus=0,unit=0 -drive file=2.img,media=disk,if=scsi,bus=0,unit=1 -drive file=3.img,media=disk,if=scsi,bus=0,unit=2 -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -option-rom BIOS/V4.19/8xx_64.rom -device rtl8139,mac=00:02:44:92:87:6a,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0 Backtrace isn't valid. Old integrated BIOS is valid and works well. Ciao, Gerhard On 17.04.2012 12:11, Gerd Hoffmann wrote: Hi, This patch series switches the vgabios binaries shipped by qemu from the lgpl'ed vgabios to the seabios version. There should be no guest-visible changes (especially no regressions) in theory. The only known (and intentional) exception is the vesa 2.0 protected mode interface which is not implemented by the seavgabios. There are no known issues with linux and windows guests. Testing with other, more exotic guests is very welcome. Note #1: Just pull from git to test, I've zapped the big binary patches so you can't 'git am' them. Note #2: This goes on top of the seabios-1.7.0 pull request just sent, so pulling this will pull the seabios update too. please give it a spin, Gerd The following changes since commit 6b034aa138716a515c88f7894940d5d0aff2f3ed: seabios: update to 1.7.0 (2012-04-17 10:51:41 +0200) are available in the git repository at: git://git.kraxel.org/qemu seavgabios-1.7.0 Gerd Hoffmann (3): Add seavgabios build rules to roms/Makefile Update vgabios binaries Switch isa vga to seavgabios too. hw/vga-isa.c |2 +- hw/vga_int.h |1 - pc-bios/vgabios-cirrus.bin | Bin 35840 -> 37888 bytes pc-bios/vgabios-isavga.bin | Bin 0 -> 37888 bytes pc-bios/vgabios-qxl.bin| Bin 40448 -> 37888 bytes pc-bios/vgabios-stdvga.bin | Bin 40448 -> 37888 bytes pc-bios/vgabios-vmware.bin | Bin 40448 -> 37888 bytes roms/Makefile | 13 + roms/config.vga.cirrus |3 +++ roms/config.vga.isavga |3 +++ roms/config.vga.qxl|6 ++ roms/config.vga.stdvga |3 +++ roms/config.vga.vmware |6 ++ 13 files changed, 35 insertions(+), 2 deletions(-) create mode 100644 pc-bios/vgabios-isavga.bin create mode 100644 roms/config.vga.cirrus create mode 100644 roms/config.vga.isavga create mode 100644 roms/config.vga.qxl create mode 100644 roms/config.vga.stdvga create mode 100644 roms/config.vga.vmware
Re: [Qemu-devel] DOS VM problem with QEMU-KVM and newer kernels
On 15.04.2012 11:44, Avi Kivity wrote: On 04/12/2012 09:32 PM, Gerhard Wiesinger wrote: Hello, I'm having problems with recents kernels and qemu-kvm with a DOS VM: TD286 System: Bad selector: 0007 System: Bad selector: 0D87 System: Bad selector: 001F System: Bad selector: 0007 GP at 0020 21D4 EC 0DC4 Error 269 loading D:\BP\BIN\TD286.EXE into extended memory Another 286 DOS Extender application also rises a general protection fault: GP at 0020 18A1 CODE 357C Doesn't depend on the used DOS memory manager and is always reproduceable. Depends only on kernel version and not qemu-kvm and seabios (tried to bisect it without success): # NOK: Linux 3.3.1-3.fc16.x86_64 #1 SMP Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # NOK: Linux 3.2.10-3.fc16.x86_64 #1 SMP Thu Mar 15 19:39:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 2.6.41.9-1.fc15.x86_64 #1 SMP Fri Jan 13 16:46:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux CPU is an AMD one. Any ideas how to fix it again? Any switches which might help? The trigger is probably commit f1c1da2bde712812a3e0f9a7a7ebe7a916a4b5f4 Author: Jan Kiszka Date: Tue Oct 18 18:23:11 2011 +0200 KVM: SVM: Keep intercepting task switching with NPT enabled AMD processors apparently have a bug in the hardware task switching support when NPT is enabled. If the task switch triggers a NPF, we can get wrong EXITINTINFO along with that fault. On resume, spurious exceptions may then be injected into the guest. We were able to reproduce this bug when our guest triggered #SS and the handler were supposed to run over a separate task with not yet touched stack pages. Work around the issue by continuing to emulate task switches even in NPT mode. Signed-off-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Although it's not the patch's direct fault - it simply exposed an existing bug in kvm. Things to try: - revert the patch with a newer kernel - try 3.4-rc2 which has some task switch fixes from Kevin; if you want a Fedora kernel, use rawhide's [2] - post traces [1] Jan, Joerg, was an AMD erratum published for the bug? [1] http://www.linux-kvm.org/page/Tracing [2] http://mirrors.kernel.org/fedora/development/rawhide/x86_64/os/Packages/k/kernel-3.4.0-0.rc2.git2.1.fc18.x86_64.rpm Hello Avi, Status is as follows: 1.) Kernel 3.4.x DIDN'T fix the problem 2.) Reverting f1c1da2bde712812a3e0f9a7a7ebe7a916a4b5f4 FIXED the problem. So the bug is still in 3.2., 3.3, 3.4rc present and a possible fix doesn't work. Should be fixed in 3.4 release. How to proceed further? I can try some patches if you want. Thnx for all your help. Ciao, Gerhard
Re: [Qemu-devel] DOS VM problem with QEMU-KVM and newer kernels
On Mon, 16 Apr 2012, Avi Kivity wrote: On 04/16/2012 01:30 PM, Roedel, Joerg wrote: On Mon, Apr 16, 2012 at 12:25:37PM +0200, Jan Kiszka wrote: On 2012-04-15 11:44, Avi Kivity wrote: Jan, Joerg, was an AMD erratum published for the bug? It wasn't an erratum but a documented feature limitation in the AMD architecture that was simply ignored by the old code. Right. But there is an erratum on K8 (only) which Kevin ran into. It is documented as Erratum 701 and the bug is that no EXITINTINFO is stored on a task-switch intercept on K8. Ah, so this could affect Gerhard. Gerhard, what's your cpu family/model/stepping from /proc/cpuinfo? Only CPU 0 of 3: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 940 Processor stepping: 2 microcode : 0x186 cpu MHz : 2999.912 cache size : 512 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save bogomips: 5999.82 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate part of cpuid, CPU 0: vendor_id = "AuthenticAMD" version information (1/eax): processor type = primary processor (0) family = Intel Pentium 4/Pentium D/Pentium Extreme Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon XP-M/Opteron/Sempron/Turion (15) model = 0x4 (4) stepping id = 0x2 (2) extended family = 0x1 (1) extended model = 0x0 (0) (simple synth) = AMD Quad-Core Opteron (Shanghai RB-C2) / Embedded Opteron (Shanghai RB-C2) / Athlon Dual-Core (Regor / Propus RB-C2) / Phenom II (Callisto / Heka / Deneb RB-C2), 45nm miscellaneous (1/ebx): process local APIC physical ID = 0x0 (0) cpu count = 0x4 (4) CLFLUSH line size = 0x8 (8) brand index= 0x0 (0) brand id = 0x00 (0): unknown Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] DOS VM problem with QEMU-KVM and newer kernels
On 15.04.2012 11:44, Avi Kivity wrote: On 04/12/2012 09:32 PM, Gerhard Wiesinger wrote: Hello, I'm having problems with recents kernels and qemu-kvm with a DOS VM: TD286 System: Bad selector: 0007 System: Bad selector: 0D87 System: Bad selector: 001F System: Bad selector: 0007 GP at 0020 21D4 EC 0DC4 Error 269 loading D:\BP\BIN\TD286.EXE into extended memory Another 286 DOS Extender application also rises a general protection fault: GP at 0020 18A1 CODE 357C Doesn't depend on the used DOS memory manager and is always reproduceable. Depends only on kernel version and not qemu-kvm and seabios (tried to bisect it without success): # NOK: Linux 3.3.1-3.fc16.x86_64 #1 SMP Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # NOK: Linux 3.2.10-3.fc16.x86_64 #1 SMP Thu Mar 15 19:39:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 2.6.41.9-1.fc15.x86_64 #1 SMP Fri Jan 13 16:46:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux CPU is an AMD one. Any ideas how to fix it again? Any switches which might help? The trigger is probably commit f1c1da2bde712812a3e0f9a7a7ebe7a916a4b5f4 Author: Jan Kiszka Date: Tue Oct 18 18:23:11 2011 +0200 KVM: SVM: Keep intercepting task switching with NPT enabled AMD processors apparently have a bug in the hardware task switching support when NPT is enabled. If the task switch triggers a NPF, we can get wrong EXITINTINFO along with that fault. On resume, spurious exceptions may then be injected into the guest. We were able to reproduce this bug when our guest triggered #SS and the handler were supposed to run over a separate task with not yet touched stack pages. Work around the issue by continuing to emulate task switches even in NPT mode. Signed-off-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Although it's not the patch's direct fault - it simply exposed an existing bug in kvm. Things to try: - revert the patch with a newer kernel - try 3.4-rc2 which has some task switch fixes from Kevin; if you want a Fedora kernel, use rawhide's [2] - post traces [1] Jan, Joerg, was an AMD erratum published for the bug? [1] http://www.linux-kvm.org/page/Tracing [2] http://mirrors.kernel.org/fedora/development/rawhide/x86_64/os/Packages/k/kernel-3.4.0-0.rc2.git2.1.fc18.x86_64.rpm Hello Avi, Tried newer kernel since this version is no longer available: http://mirrors.kernel.org/fedora/development/rawhide/x86_64/os/Packages/k/kernel-3.4.0-0.rc2.git3.1.fc18.x86_64.rpm But I wasn't successfull. Still same GP fault (but with 18A2 instead of 18A1): GP at 0020 18A2 CODE 357C yum install asciidoc udis86 udis86-devel git clone git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git cd trace-cmd make ./trace-cmd record -b 2 -e kvm ./trace-cmd report Very long output, what should I grep/trigger for? Thnx so far. BTW: Where can I find old kernels like (removed on upgrade :-( ): kernel-2.6.41.9-1.fc15.x86_64.rpm kernel-3.1.9-1.fc16.x86_64.rpm kernel-3.2.10-3.fc16.x86_64.rpm kernel-debug-2.6.41.9-1.fc15.x86_64 Ciao, Gerhard
[Qemu-devel] DOS VM problem with QEMU-KVM and newer kernels
Hello, I'm having problems with recents kernels and qemu-kvm with a DOS VM: TD286 System: Bad selector: 0007 System: Bad selector: 0D87 System: Bad selector: 001F System: Bad selector: 0007 GP at 0020 21D4 EC 0DC4 Error 269 loading D:\BP\BIN\TD286.EXE into extended memory Another 286 DOS Extender application also rises a general protection fault: GP at 0020 18A1 CODE 357C Doesn't depend on the used DOS memory manager and is always reproduceable. Depends only on kernel version and not qemu-kvm and seabios (tried to bisect it without success): # NOK: Linux 3.3.1-3.fc16.x86_64 #1 SMP Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # NOK: Linux 3.2.10-3.fc16.x86_64 #1 SMP Thu Mar 15 19:39:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # OK: Linux 2.6.41.9-1.fc15.x86_64 #1 SMP Fri Jan 13 16:46:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux CPU is an AMD one. Any ideas how to fix it again? Any switches which might help? Thnx. Ciao, Gerhard
Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.
On Thu, 5 Apr 2012, Yan Vugenfirer wrote: On Thu, Apr 5, 2012 at 8:25 AM, Gerhard Wiesinger wrote: On Wed, 4 Apr 2012, Izik Eidus wrote: What about this patch?, everything that was asked from Dmitry was accomplished... What prevent us from progressing with merging this patch? As already discussed on the list patch v5 doesn't work at least for me. Previous patches worked better but were not stable under load. I'm also appreciating a working version and integrating the patch fast. Ciao, Gerhard -- http://www.wiesinger.com/ Hello Gerhard, 1. I understand that you send your exact command line to Dmitry and your test scripts, but we cannot reproduce the issues. Can you send us host network configuration? 2. Is it possible for you to run tcpdump on the guest and on the host and send us the files for review? Since there was no difference for v5 patch, I already sent this for v4 patch: See: https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04062.html https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04634.html I also sniffed between working NIC (rtl8139) and non working NIC (vmxnet3) and as already thought in //lists.gnu.org/archive/html/qemu-devel/2012-03/msg04062.html TCP offloading checksum is NOT correct. From wireshark sniff: Checksum SYN1: 0xe937 [incorrect, should be 0xe936 (maybe caused by "TCP checksum offload"?)] Checksum SYN2: [incorrect, should be 0xe5af (maybe caused by "TCP checksum offload"?)] => checksum is always too high by 1. Please fix it. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.
On Wed, 4 Apr 2012, Izik Eidus wrote: What about this patch?, everything that was asked from Dmitry was accomplished... What prevent us from progressing with merging this patch? As already discussed on the list patch v5 doesn't work at least for me. Previous patches worked better but were not stable under load. I'm also appreciating a working version and integrating the patch fast. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
Hello Dmitry, Tried it also on qemu, without success. Same behavior. I sniffed also with tcpdump: ICMP traffic is dumped immediately but TCP traffic not. Looks like a TCP problem. For config and other details see below. Ciao, Gerhard On 21.03.2012 07:59, Gerhard Wiesinger wrote: On 20.03.2012 09:00, Dmitry Fleytman wrote: Hello, Gerhard I've tested telnet connections on Knoppix running on QEMU-KVM with patch V5. Everything works fine on my setup. What is your network setup? How do you connect tap1 interface to the outer world? Hello Dmitry , Did you also test with tap? As patch V2 (i think it was that version) worked well but was not stable I'm guessing that there might be some other problems: 1.) tap interface? 2.) TCP offload checksumming (as far as I saw I think there were some changes). Same command line with pcnet is also ok (changed only interface card). My network setup for testing several adapters is stable since about one year. /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 I use a bridge on eth0 and connect the tap interfaces: brctl show bridge name bridge id STP enabled interfaces br0 8000.001fc689da45 no eth0 tap0 tap1 Also, since you have ping failure to init MSI-X is not related to the problem - device just falls back to MSI interrupts, but anyway, why does it fail? Could it be some QEMU/KVM versions incompartibility? Don't know why it fails. I'm using latest git QEMU/KVM version. Will try it on qemu only today in the evening. Thnx. Ciao, Gerhard Best regards, Dmitry Fleytman. On Mon, Mar 19, 2012 at 9:24 PM, Gerhard Wiesinger wrote: Hello Dmitry, Tried also v5 patch without success: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 ping ok, but outside tcp communication fails: # timeout Knoppix => outside telnet 192.168.0.2 22 # timeout outside => Knoppix failes telnet 192.168.0.30 22 RTL8139 with same command line is ok. Maybe that helps directly at startup: kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 [vmxnet3][WR][vmxnet3_pci_init]: Failed to initialize MSI-X, configuration is inconsistent. [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. I'm using git qemu-kvm and not git qemu. Thnx. Ciao, Gerhard On 18.03.2012 16:30, Dmitry Fleytman wrote: Hello, Gerhard I've rechecked SSH connection both incoming and outgoing with patch v5. Everything works fine. If you still see problems, please, provide your exact configuration. Thanking you for your support, Dmitry Fleytman. On Sun, Mar 18, 2012 at 10:29 AM, Gerhard Wiesinger wrote: Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no v
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
On 20.03.2012 09:00, Dmitry Fleytman wrote: Hello, Gerhard I've tested telnet connections on Knoppix running on QEMU-KVM with patch V5. Everything works fine on my setup. What is your network setup? How do you connect tap1 interface to the outer world? Hello Dmitry , Did you also test with tap? As patch V2 (i think it was that version) worked well but was not stable I'm guessing that there might be some other problems: 1.) tap interface? 2.) TCP offload checksumming (as far as I saw I think there were some changes). Same command line with pcnet is also ok (changed only interface card). My network setup for testing several adapters is stable since about one year. /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 I use a bridge on eth0 and connect the tap interfaces: brctl show bridge name bridge id STP enabled interfaces br0 8000.001fc689da45 no eth0 tap0 tap1 Also, since you have ping failure to init MSI-X is not related to the problem - device just falls back to MSI interrupts, but anyway, why does it fail? Could it be some QEMU/KVM versions incompartibility? Don't know why it fails. I'm using latest git QEMU/KVM version. Will try it on qemu only today in the evening. Thnx. Ciao, Gerhard Best regards, Dmitry Fleytman. On Mon, Mar 19, 2012 at 9:24 PM, Gerhard Wiesinger wrote: Hello Dmitry, Tried also v5 patch without success: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 ping ok, but outside tcp communication fails: # timeout Knoppix => outside telnet 192.168.0.2 22 # timeout outside => Knoppix failes telnet 192.168.0.30 22 RTL8139 with same command line is ok. Maybe that helps directly at startup: kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 [vmxnet3][WR][vmxnet3_pci_init]: Failed to initialize MSI-X, configuration is inconsistent. [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. I'm using git qemu-kvm and not git qemu. Thnx. Ciao, Gerhard On 18.03.2012 16:30, Dmitry Fleytman wrote: Hello, Gerhard I've rechecked SSH connection both incoming and outgoing with patch v5. Everything works fine. If you still see problems, please, provide your exact configuration. Thanking you for your support, Dmitry Fleytman. On Sun, Mar 18, 2012 at 10:29 AM, Gerhard Wiesinger wrote: Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Re
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
Hello Dmitry, Tried also v5 patch without success: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 ping ok, but outside tcp communication fails: # timeout Knoppix => outside telnet 192.168.0.2 22 # timeout outside => Knoppix failes telnet 192.168.0.30 22 RTL8139 with same command line is ok. Maybe that helps directly at startup: kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 [vmxnet3][WR][vmxnet3_pci_init]: Failed to initialize MSI-X, configuration is inconsistent. [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. I'm using git qemu-kvm and not git qemu. Thnx. Ciao, Gerhard On 18.03.2012 16:30, Dmitry Fleytman wrote: Hello, Gerhard I've rechecked SSH connection both incoming and outgoing with patch v5. Everything works fine. If you still see problems, please, provide your exact configuration. Thanking you for your support, Dmitry Fleytman. On Sun, Mar 18, 2012 at 10:29 AM, Gerhard Wiesinger wrote: Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Reformatting comments according to checkpatch.pl requirements Adding utility function net_checksum_add_cont() that allows checksum calculation of scattered data with odd chunk sizes Adding utility function iov_net_csum_add() for iovec checksum calculation MSI-X state save/load invocations moved to PCI Device save/load callbacks to avoid code duplication in MSI-X-enabled devices that support live migration Header with various utility functions shared by VMWARE SCSI and network devi Various utility functions used by VMWARE network devices Packet abstraction used by VMWARE network devices VMXNET3 paravirtual device implementation VMXNET3 paravirtualized device integration. Interface type "vmxnet3" added. Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.c|7 + hw/pci.h|1 + hw/virtio-net.h | 13 +- hw/virtio-pci.c |2 - hw/vmware_utils.h | 122 +++ hw/vmxnet3.c| 2435 +++ hw/vmxnet3.h| 757 +++ hw/vmxnet_debug.h | 121 +++ hw/vmxnet_pkt.c | 1243 hw/vmxnet_pkt.h | 479 ++ hw/vmxnet_utils.c | 165 hw/vmxnet_utils.h | 320 +++ iov.c | 29 + iov.h |3 + net.c |2 +- net/checksum.c | 13 +- net/checksum.h | 14 +- 19 files changed, 5712 insertions(+), 16 deletions(-) create mode 100644 hw/vmware_utils.h create mode 100644 hw/vmxnet3.c create mode 100644 hw/vmxnet3.h create mode 100644 hw/vmxnet_debug.h create mode 100644 hw/vmxnet_pkt.c create mode 100644 hw/vmxnet_pkt.h create mode 100644 hw/vmxnet_utils.c create mode 100644 hw/vmxnet_utils.h
Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation
Hello Dmitry, Is PVSCSI also ready to boot through BIOS Int 13h? If not, do you plan a SEABIOS patch? Thnx. Ciao, Gerhard On 15.03.2012 10:02, Dmitry Fleytman wrote: Below is the implementation of VMWare PVSCSI device and command line parameters to configure vendor name and product name for SCSI storage are implemented. Latter is needed to make PVSCSI storage devices look exactly as on VMWare hypervisors. With this and VMWARE3 patches V2V migration problem for VMWare images should be solved relatively easy. PVSCSI implementation is based on Paolo Bonzini code sumbitted some time ago but never applied. See commit messages and file headers for details. Implementation supports of all the device features. Code was tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Dmitry Fleytman (5): Utility function strpadcpy() added Vendor name and product name parameters for SCSI devices Options "vendor_name" and "product_name" added for SCSI disks. Header with various utility functions shared by VMWARE SCSI and network devices PVCSI paravirtualized device implementation PVSCSI paravirtualized device integration Bus type "pvscsi" added. Makefile.objs |1 + blockdev.c | 12 +- blockdev.h | 16 +- cutils.c | 13 + default-configs/pci.mak|1 + docs/specs/pvscsi-spec.txt | 92 hw/pc.c|5 + hw/pci-hotplug.c |7 +- hw/pci.h |1 + hw/pvscsi.c| 1242 hw/pvscsi.h| 442 hw/scsi-bus.c | 14 +- hw/scsi-disk.c | 51 ++- hw/scsi.h |1 + hw/vmware_utils.h | 122 + qemu-common.h |1 + 16 files changed, 1997 insertions(+), 24 deletions(-) create mode 100644 docs/specs/pvscsi-spec.txt create mode 100644 hw/pvscsi.c create mode 100644 hw/pvscsi.h create mode 100644 hw/vmware_utils.h
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Reformatting comments according to checkpatch.pl requirements Adding utility function net_checksum_add_cont() that allows checksum calculation of scattered data with odd chunk sizes Adding utility function iov_net_csum_add() for iovec checksum calculation MSI-X state save/load invocations moved to PCI Device save/load callbacks to avoid code duplication in MSI-X-enabled devices that support live migration Header with various utility functions shared by VMWARE SCSI and network devi Various utility functions used by VMWARE network devices Packet abstraction used by VMWARE network devices VMXNET3 paravirtual device implementation VMXNET3 paravirtualized device integration. Interface type "vmxnet3" added. Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.c|7 + hw/pci.h|1 + hw/virtio-net.h | 13 +- hw/virtio-pci.c |2 - hw/vmware_utils.h | 122 +++ hw/vmxnet3.c| 2435 +++ hw/vmxnet3.h| 757 +++ hw/vmxnet_debug.h | 121 +++ hw/vmxnet_pkt.c | 1243 hw/vmxnet_pkt.h | 479 ++ hw/vmxnet_utils.c | 165 hw/vmxnet_utils.h | 320 +++ iov.c | 29 + iov.h |3 + net.c |2 +- net/checksum.c | 13 +- net/checksum.h | 14 +- 19 files changed, 5712 insertions(+), 16 deletions(-) create mode 100644 hw/vmware_utils.h create mode 100644 hw/vmxnet3.c create mode 100644 hw/vmxnet3.h create mode 100644 hw/vmxnet_debug.h create mode 100644 hw/vmxnet_pkt.c create mode 100644 hw/vmxnet_pkt.h create mode 100644 hw/vmxnet_utils.c create mode 100644 hw/vmxnet_utils.h
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesinger Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguori Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesinger Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Reformatting comments according to checkpatch.pl requirements Adding utility function net_checksum_add_cont() that allows checksum calculation of scattered data with odd chunk sizes Adding utility function iov_net_csum_add() for iovec checksum calculation MSI-X state save/load invocations moved to PCI Device save/load callbacks to avoid code duplication in MSI-X-enabled devices that support live migration Header with various utility functions shared by VMWARE SCSI and network devi Various utility functions used by VMWARE network devices Packet abstraction used by VMWARE network devices VMXNET3 paravirtual device implementation VMXNET3 paravirtualized device integration. Interface type "vmxnet3" added. Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.c|7 + hw/pci.h|1 + hw/virtio-net.h | 13 +- hw/virtio-pci.c |2 - hw/vmware_utils.h | 122 +++ hw/vmxnet3.c| 2435 +++ hw/vmxnet3.h| 757 +++ hw/vmxnet_debug.h | 121 +++ hw/vmxnet_pkt.c | 1243 hw/vmxnet_pkt.h | 479 ++ hw/vmxnet_utils.c | 165 hw/vmxnet_utils.h | 320 +++ iov.c | 29 + iov.h |3 + net.c |2 +- net/checksum.c | 13 +- net/checksum.h | 14 +- 19 files changed, 5712 insertions(+), 16 deletions(-) create mode 100644 hw/vmware_utils.h create mode 100644 hw/vmxnet3.c create mode 100644 hw/vmxnet3.h create mode 100644 hw/vmxnet_debug.h create mode 100644 hw/vmxnet_pkt.c create mode 100644 hw/vmxnet_pkt.h create mode 100644 hw/vmxnet_utils.c create mode 100644 hw/vmxnet_utils.h
Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation
Hello Dmitry, Is PVSCSI also ready to boot through BIOS Int 13h? If not, do you plan a SEABIOS patch? Thnx. Ciao, Gerhard On 15.03.2012 10:02, Dmitry Fleytman wrote: Below is the implementation of VMWare PVSCSI device and command line parameters to configure vendor name and product name for SCSI storage are implemented. Latter is needed to make PVSCSI storage devices look exactly as on VMWare hypervisors. With this and VMWARE3 patches V2V migration problem for VMWare images should be solved relatively easy. PVSCSI implementation is based on Paolo Bonzini code sumbitted some time ago but never applied. See commit messages and file headers for details. Implementation supports of all the device features. Code was tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Dmitry Fleytman (5): Utility function strpadcpy() added Vendor name and product name parameters for SCSI devices Options "vendor_name" and "product_name" added for SCSI disks. Header with various utility functions shared by VMWARE SCSI and network devices PVCSI paravirtualized device implementation PVSCSI paravirtualized device integration Bus type "pvscsi" added. Makefile.objs |1 + blockdev.c | 12 +- blockdev.h | 16 +- cutils.c | 13 + default-configs/pci.mak|1 + docs/specs/pvscsi-spec.txt | 92 hw/pc.c|5 + hw/pci-hotplug.c |7 +- hw/pci.h |1 + hw/pvscsi.c| 1242 hw/pvscsi.h| 442 hw/scsi-bus.c | 14 +- hw/scsi-disk.c | 51 ++- hw/scsi.h |1 + hw/vmware_utils.h | 122 + qemu-common.h |1 + 16 files changed, 1997 insertions(+), 24 deletions(-) create mode 100644 docs/specs/pvscsi-spec.txt create mode 100644 hw/pvscsi.c create mode 100644 hw/pvscsi.h create mode 100644 hw/vmware_utils.h
Re: [Qemu-devel] [PATCH 1/1] vmware_vga: stop crashing
Can confirm that this patch fixes a crash which also occoured here. Since
window was out of the VNC window, crash was reproduceable and has been
removed reproduceable.
Tested-by: Gerhard Wiesinger
Please apply ASAP.
Ciao,
Gerhard
--
http://www.wiesinger.com/
On Mon, 5 Mar 2012, Serge Hallyn wrote:
if x or y < 0, set them to 0 (and decrement width/height accordingly)>
I don't know where the best place to catch this would be, but
with vnc and vmware_vga it's possible to get set_bit called on
a negative index, crashing qemu. See
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/918791
for details. This patch prevents that. It's possible this
should be caught earlier, but this patch works for me.
Changelog:
Mar 5: As Ryan Harper pointed out, don't mix tabs+spaces,
and put {} around all conditionals.
Signed-off-by: Serge Hallyn
---
hw/vmware_vga.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 142d9f4..c94f9f3 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -298,6 +298,24 @@ static inline void vmsvga_update_rect(struct
vmsvga_state_s *s,
uint8_t *src;
uint8_t *dst;
+if (x < 0) {
+fprintf(stderr, "%s: update x was < 0 (%d, w %d)\n",
+__FUNCTION__, x, w);
+w += x;
+if (w < 0) {
+return;
+}
+x = 0;
+}
+if (y < 0) {
+fprintf(stderr, "%s: update y was < 0 (%d, h %d)\n",
+__FUNCTION__, y, h);
+h += y;
+if (h < 0) {
+return;
+}
+y = 0;
+}
if (x + w > s->width) {
fprintf(stderr, "%s: update width too large x: %d, w: %d\n",
__FUNCTION__, x, w);
--
1.7.9
Re: [Qemu-devel] Compile error at master HEAD of repository (7c51c1aa03a52b9fd75ed1ade2e65d079ae4d50e)
Has been fixed with commit 0202181245297a9e847c05f4a18623219d95e93e BTW: Is also a gcc 4.6.2 issue. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Thu, 1 Mar 2012, Gerhard Wiesinger wrote: Hello, qemu repository is not compile clean. I'm getting the following compile erors: CClibcacard/vcard_emul_nss.o vcard_emul_nss.c:528:47: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:57: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:63: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:69: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:74: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:79: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:84: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:89: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:94: error: left-hand operand of comma expression has no effect [-Werror=unused-value] vcard_emul_nss.c:528:1: error: initializer element is not constant vcard_emul_nss.c:528:1: error: (near initialization for .nss_atr[0].) cc1: all warnings being treated as errors make[1]: *** [vcard_emul_nss.o] Error 1 make: *** [subdir-libcacard] Error 2 Any ideas? Can someone commit a fix. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
On Fri, 9 Mar 2012, Gerd Hoffmann wrote: Hi, #2 isn't an issue actually, at least for Debian users -- Well, it is, to some degree. Because vanilla upstream doesn't support booting from lsi it has alot less users and alot less regression testing (like autotest runs of lsi-scsi installs), which sums up to more bugs staying unnoticed like the one which triggered this thread. What's the holdup to integrate it into QEMU? Extboot is considered obsolete and thus several attempts to merge it into upstream qemu failed. It started its life as hack to allow qemu-kvm boot from virtio-blk devices, which happened to work for lsi too. virtio-blk is supported by seabios natively these days. Adding lsi support to seabios shouldn't be that hard. Paolo paved the way by restructing the existing scsi disk/cdrom bits in seabios so they work for both usb-storage and virtio-scsi. Adding support for yet another scsi hba should be easy, all the support bits for handling disks and booting from cdrom are there already. It just needs someone to sit down for a week or two and hack it up. @Paolo: Would that be easily possible? BTW: What do you think anout that: Handling INT13h always directly through virtio-scsi regardless of selected SCSI adapter, or when OS driver is loaded through SCSI adapter, so just have 2 ways to the disks: 1.) Through INT13h to virtio-scsi and then to the disks 2.) Through SCSI adapter and then to the disks (OS driver loaded) Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] [PATCH v3] VMXNET3 paravirtual NIC device implementation
Hello Dmitry, Issue is solved in V3 but I'm still having problems (core dumps) with qemu and qemu-kvm: 1.) qemu crashes works well with basic ping tests but with generating load on the network interface (my standard netio tests (netio -s, netio -t server), http://www.ars.de/ars/ars.nsf/docs/netio) under same Knoppix testcase cores. Details are below. Also performance as far as the test runs was not high (should be 5 kByte/s): Packet size 1k bytes: 4181 KByte/s Tx, 5276 KByte/s Rx. Details below. 2.) qemu-kvm core dump on startup, core dump details below -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 qemu: hardware error: Failed to initialize MSI-X, configuration is inconsistent. Any ideas? Can you please retest this scenario. Please add Reported-by lines ... Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ 1.) qemu backtrace [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. qemu-system-x86_64: /root/download/qemu/git/qemu/hw/vmxnet_utils.c:186: eth_setup_ip4_fragmentation: Assertion `0 == frag_offset % (8)' failed. #0 0x7f5f53c03285 in raise () from /lib64/libc.so.6 #1 0x7f5f53c04b9b in abort () from /lib64/libc.so.6 #2 0x7f5f53bfbe9e in __assert_fail_base () from /lib64/libc.so.6 #3 0x7f5f53bfbf42 in __assert_fail () from /lib64/libc.so.6 #4 0x7f5f564ce378 in eth_setup_ip4_fragmentation (l2hdr=, l2hdr_len=, l3hdr=,l3hdr_len=, l3payload_len=, frag_offset=, more_frags=false)at /root/download/qemu/git/qemu/hw/vmxnet_utils.c:186 #5 0x7f5f564cd325 in vmxnet3_txpkt_do_sw_fragmentation (s=0x7f5f57c340a0, p=0x7f5f57c35340)at /root/download/qemu/git/qemu/hw/vmxnet3.c:955 #6 0x7f5f564cdac1 in vmxnet3_send_with_sw_offloads (pkt=, s=0x7f5f57c340a0) at /root/download/qemu/git/qemu/hw/vmxnet3.c:985 #7 vmxnet3_send_packet (qidx=0, pkt=, s=) at /root/download/qemu/git/qemu/hw/vmxnet3.c:1231 #8 vmxnet3_process_tx_queue (qidx=, s=) at /root/download/qemu/git/qemu/hw/vmxnet3.c:1306 #9 vmxnet3_io_bar0_write (opaque=, addr=, val=, size=)at /root/download/qemu/git/qemu/hw/vmxnet3.c:1630 #10 0x7f5f56575ba0 in access_with_adjusted_size (addr=1536, value=0x7f5f3144e7e0, size=4, access_size_min=,access_size_max=, access=0x7f5f56575ac0 , opaque=0x7f5f57c344d0)at /root/download/qemu/git/qemu/memory.c:359 #11 0x7f5f5657a6ec in memory_region_dispatch_write (size=4, data=39, addr=1536, mr=0x7f5f57c344d0)at /root/download/qemu/git/qemu/memory.c:928 #12 io_mem_write (io_index=, addr=1536, val=, size=4) at /root/download/qemu/git/qemu/memory.c:1512 #13 0x49463183 in ?? () #14 0x in ?? () 2.) qemu-kvm backtrace #0 0x7f25e4330285 in raise () from /lib64/libc.so.6 #1 0x7f25e4331b9b in abort () from /lib64/libc.so.6 #2 0x7f25e6c6fe7a in hw_error (fmt=) at /root/download/qemu/git/qemu-kvm/cpus.c:357 #3 0x7f25e6bf1f01 in vmxnet3_pci_init (dev=0x7f25e8dced80) at /root/download/qemu/git/qemu-kvm/hw/vmxnet3.c:2631 #4 0x7f25e6ce01c6 in pci_qdev_init (qdev=0x7f25e8dced80) at /root/download/qemu/git/qemu-kvm/hw/pci.c:1589 #5 0x7f25e6c14d4a in qdev_init (dev=0x7f25e8dced80) at /root/download/qemu/git/qemu-kvm/hw/qdev.c:150 #6 0x7f25e6c1024e in qdev_device_add (opts=0x7f25e8ccdb80) at /root/download/qemu/git/qemu-kvm/hw/qdev-monitor.c:465 #7 0x7f25e6bebff9 in device_init_func (opts=, opaque=) at /root/download/qemu/git/qemu-kvm/vl.c:1827 #8 0x7f25e6c1e492 in qemu_opts_foreach (list=, func=0x7f25e6bebfe0 , opaque=0x0,abort_on_failure=) at qemu-option.c:1053 #9 0x7f25e6b184b5 in main (argc=, argv=, envp=) at /root/download/qemu/git/qemu-kvm/vl.c:3543 On Wed, 7 Mar 2012, Dmitry Fleytman wrote: Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (1): VMXNET3 paravirtual NIC device implementation Makefile.objs |1 + default-configs/pci.mak |1 + hw/pci.c|2 + hw/pci.h|1 + hw/virtio-net.h | 13 +- hw/vmware_utils.h | 131 +++ hw/vmxnet3.c| 2744 +++ hw/vmxnet3.h| 727 + hw/vmxnet3_debug.h | 104 ++ hw/vmxnet_utils.c | 202 hw/vmxnet_utils.h | 263 + iov.c | 27 + iov.h |3 + net.c |2
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
On Thu, 8 Mar 2012, Gerd Hoffmann wrote: On 03/08/12 09:54, Michael Tokarev wrote: On 08.03.2012 11:44, Gerd Hoffmann wrote: OK, but SAS (Serial attached SCSI) is technology in the area of storage interface technology where all big storage vendors see future (e.g. they give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives (SATA 7200RPM drives with SAS interface)). The problem isn't scsi. The problem is the lsi adapter. Problem #1 is the hardware design which makes it hard to emulate it correctly and #2 that you need a non-redistributable rom file to boot from it. #2 isn't an issue actually, at least for Debian users -- Well, it is, to some degree. Because vanilla upstream doesn't support booting from lsi it has alot less users and alot less regression testing (like autotest runs of lsi-scsi installs), which sums up to more bugs staying unnoticed like the one which triggered this thread. What's the holdup to integrate it into QEMU? Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
On Thu, 8 Mar 2012, Michael Tokarev wrote: On 08.03.2012 11:44, Gerd Hoffmann wrote: On 03/07/12 20:58, Gerhard Wiesinger wrote: On Wed, 7 Mar 2012, Brian Jackson wrote: I think most people trying to use qemu for anything useful have given up on if=scsi. Some distros even disable support because they don't want to QA it. That should be a decent sign that you may want to avoid it. OK, but SAS (Serial attached SCSI) is technology in the area of storage interface technology where all big storage vendors see future (e.g. they give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives (SATA 7200RPM drives with SAS interface)). The problem isn't scsi. The problem is the lsi adapter. Problem #1 is the hardware design which makes it hard to emulate it correctly and #2 that you need a non-redistributable rom file to boot from it. #2 isn't an issue actually, at least for Debian users -- I just patched extbook back to allow booting from scsi and to let people some transition time to move from boot=on syntax which was supported before 1.0 and dropped suddenly without any warnings in 1.0, breaking people setup. I think I'll continue shipping extboot support at least as long as there's no native support for scsi booting in bios. What's extbook? Can you please explain a little bit the concept? Links? Or is it extboot option ROM? But currently not any more in qemu? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
On Thu, 8 Mar 2012, Gerd Hoffmann wrote: On 03/07/12 20:58, Gerhard Wiesinger wrote: On Wed, 7 Mar 2012, Brian Jackson wrote: I think most people trying to use qemu for anything useful have given up on if=scsi. Some distros even disable support because they don't want to QA it. That should be a decent sign that you may want to avoid it. OK, but SAS (Serial attached SCSI) is technology in the area of storage interface technology where all big storage vendors see future (e.g. they give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives (SATA 7200RPM drives with SAS interface)). The problem isn't scsi. The problem is the lsi adapter. Problem #1 is the hardware design which makes it hard to emulate it correctly and #2 that you need a non-redistributable rom file to boot from it. Advantages of LSI 53C895A over others: 1.) OS support is great, even for legacy systems: DOS, Win 3.1, Win95, NT 4, W2K, XP, Vista, Win7, Linux, etc. I don't know any adapter with such wide range of OS support. Also tested up to 2TB of LUNs. 2.) OS support out of the box without additional drivers for a lot of newer OSes 3.) Migration from VMWare SCSI is easy 4.) Works well here for about 1 year for legacy VMs for DOS and NT 4 5.) BIOS geometry translation is correct, also according to partition table (doesn't work correctly on MEGASAS, INT13 geometry interrupts are not correct, already reported to Hannes) 7.) LSI SCSI DMA technology is fast. I'm getting /dev/null performance over 500MB/s ..., optimized for parallel IOPS, etc. 8.) Faster ROM init than MEGASAS Disadvantages: 1.) ROM non distributable 2.) non complete implementation 3.) 2TB limit 4.) Slower ROM INIT than without any Option ROM Megasas also needs a ROM rom to boot from it. Not to forget iSCSI which is also current/future SCSI technology ... Even if it is hard but I think the goal of qemu should be to implement all supported hardware pieces as good as possible (e.g. LSI 53C895A). I know it is not an easy task (see my thread about rtl8139) but I think together we can manage it. Are there any LSI 53C895A known bugs or incomplete implementation issues which are known? Any hints on the core dump? Therefore I don't understand why distros are giving up SAS which is also SCSI (of course old legacy SCSI is understandable). Nobody gives up on scsi. See virtio-scsi merged recently. There also is megasas aiming for merge (which shares the boot issue with lsi though). Disadvantage of virtio-scsi is that drivers are needed. Is INT13h supported for legacy OS and to boot? Future? But as far as I saw implemented in seabios, right? What BIOS translation is used? Buslogic? LSI logic? Partition guessing? BTW: I've found out how LSI logic BIOS geometry translation works with (guessing) and without existing partition table. That might be an option for Seabios to implement. @Kevin: What do you think? Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Interpretation of key symbols in QEMU's VNC server
Hello Fabian, I'm having also isssues with german keymappings. E.g. Under DOS when pressing shift keys will always be uppercase. Also ALT-GR doesn't work. Testcase in this order: a => a a => a Shift-a => a (should be A) a => A (should be a) a => A (should be a) a => A (should be a) Shift-a => a (should be A) a => A (should be a) AltGr-? => ? (should be \) So Shift states are not correctly implemented. Also issues with CAPS-LOCK. I'm always trying with: QEMU started with: "-k de" Keyboard layout in VM: de Keyboard layout from Client OS: de I already discussed such issues here: https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg02225.html https://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00138.html Ciao, Gerhard -- http://www.wiesinger.com/ On Wed, 7 Mar 2012, Fabian Holler wrote: Hello, I'm not sure if I found a bug in QEMU's VNC keysymbol to scancode mapping or if it is a general Problem with the implemented VNC server: Scenario: QEMU started with: "-k de" Keyboard layout in VM: de Keyboard layout from Client OS: us What i expect: I type the '/' character on the Client OS (key left from the right-shift-key) on US layout. key symbol '/' is send over VNC to the QEMU. QEMU lookup in the de keyboard mapping table for the character '/' and should find the scancodes for the keys shift+'7'. The Scancodes for shift and '7' are send to the VM's emulated keyboard controller and the '/' appears in the VM. But what actually happens is that the '7' character shows up in the VM. It seems that QEMU misses to generates an additional Shift Scancode/Keypress. Is this a general problem in the VNC server implementation? So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4) of the received key symbols to eg add an additional shift keypress isn't implemented? If yes, would a QEMU patch that adds keysymbol interpretation have a chance to be merged into upstream? Or are there reasons that it isn't a good idea to interpret the VNC keysymbols and add/remove additional needed scancodes to get the expected character on the VM? regards Fabian
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
On Wed, 7 Mar 2012, Brian Jackson wrote: I think most people trying to use qemu for anything useful have given up on if=scsi. Some distros even disable support because they don't want to QA it. That should be a decent sign that you may want to avoid it. OK, but SAS (Serial attached SCSI) is technology in the area of storage interface technology where all big storage vendors see future (e.g. they give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives (SATA 7200RPM drives with SAS interface)). Therefore I don't understand why distros are giving up SAS which is also SCSI (of course old legacy SCSI is understandable). And legacy SCSI is of course technology from yesterday but e.g. LSI53C895A has largest OS support ever as far as I know (from DOS, Win95, NT4, W2K, XP, Vista, Windows 7, Linux, etc.). Also CPU usage is low. What's your preferred storage technology on QEMU? Where do you see future? BTW: The underlying problem I want to solve: I want to migrate a VMWare Server 2.x VM based on Buslogic SCSI controller to QEMU/KVM. And geometry translation to IDE/SATA doesn't boot up the system ... Any ideas to migrate to other storage technology (VM is offline)? Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
Ping. Any comments? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Sun, 4 Mar 2012, Gerhard Wiesinger wrote: Hello, Clean XP install cores with SCSI LSI 53C89A disk when copying files. Reproduceable. Driver used is sym_hi. Details are below. Tried also old versions 1.0, 0.15.1, cores too. Any ideas? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ Image created with: qemu-img create -f qcow2 XP-TEST.qcow2 10G Command line: Version: git b5ed4b6f6f0d31e0d8210f4b444ba67bfa5d6de2 /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0 -cdrom ISO/XP.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -option-rom BIOS/V4.19/8xx_64.rom -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 #0 0x7f66a29e5117 in malloc_consolidate.part.3 () from /lib64/libc.so.6 #1 0x7f66a29e5e99 in _int_free () from /lib64/libc.so.6 #2 0x7f66a64a1444 in scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272 #3 scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268 #4 0x7f66a64a2445 in scsi_device_purge_requests (sdev=0x7f66a9616160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421 #5 0x7f66a64a2d27 in scsi_disk_reset (dev=0x7f66a9616160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498 #6 0x7f66a643dd60 in lsi_reg_writeb (s=0x7f66a95fa140, offset=out>, val=)at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684 #7 0x7f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecbb0, size=1, access_size_min=, access_size_max=, access=0x7f66a65186c0 , opaque=0x7f66a95fa5a8)at /root/download/qemu/git/qemu-kvm/memory.c:304 #8 0x7f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66a95fa5a8) at /root/download/qemu/git/qemu-kvm/memory.c:982 #9 io_mem_write (io_index=, addr=1, val=, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564 #10 0x7f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecc60, size=1, access_size_min=, access_size_max=, access=0x7f66a65186c0 , opaque=0x7f669801bae0)at /root/download/qemu/git/qemu-kvm/memory.c:304 #11 0x7f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f669801bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982 #12 io_mem_write (io_index=, addr=1, val=, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564 #13 0x7f66a64efe58 in cpu_physical_memory_rw (addr=4273938433, buf=0x7f66a6319028 , len=1, is_write=1) at /root/download/qemu/git/qemu-kvm/exec.c:3594 #14 0x7f66a650d195 in kvm_cpu_exec (env=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/kvm-all.c:1192 #15 0x7f66a64e3201 in qemu_kvm_cpu_thread_fn (arg=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/cpus.c:732 #16 0x7f66a47bbd90 in start_thread () from /lib64/libpthread.so.0 #17 0x7f66a2a57f5d in clone () from /lib64/libc.so.6 (gdb) back #0 0x7f66efb81285 in raise () from /lib64/libc.so.6 #1 0x7f66efb82b9b in abort () from /lib64/libc.so.6 #2 0x7f66efbc2a7e in __libc_message () from /lib64/libc.so.6 #3 0x7f66efbc8da6 in malloc_printerr () from /lib64/libc.so.6 #4 0x7f66efbc9279 in malloc_consolidate.part.3 () from /lib64/libc.so.6 #5 0x7f66efbc9e99 in _int_free () from /lib64/libc.so.6 #6 0x7f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272 #7 scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268 #8 0x7f66f3686445 in scsi_device_purge_requests (sdev=0x7f66f6b8e160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421 #9 0x7f66f3686d27 in scsi_disk_reset (dev=0x7f66f6b8e160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498 #10 0x7f66f3621d60 in lsi_reg_writeb (s=0x7f66f6b72140, offset=out>, val=)at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684 #11 0x7f66f36fc7a0 in access_with_adjusted_size (addr=1, value=0x7f66ec5d0bb0, size=1, access_size_min=, access_size_max=, access=0x7f66f36fc6c0 , opaque=0x7f66f6b725a8)at /root/download/qemu/git/qemu-kvm/memory.c:304 #12 0x7f66f37011a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66f6b725a8) at /root/download/qemu/git/qemu-kvm/memory.c:982 #13 io_mem_write (io_index=, addr=1, val=, size=1) at
Re: [Qemu-devel] RFC: rtl8139 improvements
Ping. Any comments? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Mon, 5 Mar 2012, Gerhard Wiesinger wrote: Hello, I'm trying to implement better emulation and wider OS support for the rtl8139 card. Therefore I want to see the following testcases to be successful: * Testcases and successful regression tests: * 1.) DOS RSET8139.EXE: EEPROM Test successful * 2.) DOS RSET8139.EXE: Local loopback Test (Run Diagnostics On Board) * 3.) DOS RSET8139.EXE: Remote loopback Test as Initiator (Run Diagnostics On Network) * 4.) DOS RSET8139.EXE: Remote loopback Test as Responder (Run Diagnostics On Network) * 5.) DOS driver: Loads and works * 6.) Linux tests * 7.) Windows tests I fixed already a major bug in DMA handling and (real hardware doesn't reset DMA register to 0 on reset condition as DOS driver crashes OS, see patch for details) and improved EEPROM handling and checksumming as well as unimplemented register handling (As Jason did partially in latest patch). But finally testcases 1-4 aren't successful, testcase 5 (DOS driver and MS SMB client) works but I think there are still problems, see below. Details: Ad 1.) EERPOM Test: I also copied a full EEPROM from real hardware but still no success. According to the logs everything is read correctly. Also verified checksumming to real hardware . Any ideas? (Attached rtl8139-diag.c will also help to diagnose) Ad 2.) Local Loopback Test: One packet succeeds, other fail. Any ideas what might be wrong? Ad 5.) DOS driver loads and also works but I think there is still a strange thing in packet receiving and possible sending (e.g. DHCP request is done twice). I also did some change in packet handling. See patch. To get this to work I'm a little bit lost now and I need your help and comments and suggestions. Can someone also make tests under DOS with RSET8139.EXE? I think it is a good testing program how good our emulation is. RSET8139.EXE can be found at: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=6&Level=5&Conn=4&DownTypeID=3&GetDown=false Look for DOS Diagnostic program (RSET8139). Patch is attached as diff and not indented to be used as regular patch since not ready for commit. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
