Submitted By: erikvdk
Submitted Date: 2010-03-10 14:13
Assigned To: Nobody/Anonymous

Status: Deleted
Priority: 5
Category: None
Resolution: None


Thanks to Avi Kivity I now have a workaround for this issue, namely 16-byte align the addresses in the GDT passed to the BIOS extended copy function. The BIOS left the unaligned descriptor causing MINIX to operate in unreal mode, which is not well supported by KVM on Intel.

Submitted By: jbohmdk
Submitted Date: 2010-03-07 00:44
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: None
Resolution: None


The page http://www.linux-kvm.org/page/Vista_Networking_Workaround currently contains two pieces of wrong (or at least misguided) information: Currently, the full text of that page is simply: "This issue is now resolved and Vista works with the rtl8139 driver since CVS February and newer." 1. The page says that something changed in "February", but it does not say which *year*, there is a huge difference between something changing in February 2010 or February 2008. 2. Just because some problem is solved in the CVS version of kvm (or *any* other software), it doesn't mean the change has made it to the actual real world copy of the software people are using, so any workaround, warning or other practical information for "old" bugs needs to stay available until you can be certain that the fix has been propagated all the way to all end users with regularly updated software. For a widely distributed project such as kvm, this means that all of the following must have happened: The change has made it into the "stable" release tarballs. These changed tarballs have been packaged by all distribution that previously packaged older affected releases. Those distributions have included the changed packages in released distributions or upgrades for all affected past distributions. Each distribution vendor has ended support for distribution versions containing only non-upgraded packages. At least 12 month have passed after this became true of all distributions that included the software versions affected by the issue. Yes, that is a very long time, but the only thing that needs to be done during that period is to keep the old contents available with a clear indication as to which tarballs included the problem and which tarballs included the fix, stating a CVS version or tag would be nice-to-have supplemental information but of little use for most people.

Submitted By:
Submitted Date: 2010-03-04 18:10
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: qemu
Resolution: None


qemu-kvm.git master is crashing when using -smp 1 Relevant versions: Commit hash for git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is 7811d4e8ec057d25db68f900be1f09a142faca49 (tag kvm-88-3686-g7811d4e) Kernel: 2.6.31.12-174.2.22.fc12.x86_64 Steps to reproduce 1 - Clone git repo git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git 2 - Build qemu-kvm from this repo 3 - Try to start it with -smp 1, reference command line: 03/04 12:56:12 DEBUG| kvm_vm:0461| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20100304-125508-G6lf,server,nowait -drive file=/tmp/kvm_autotest_root/images/rhel5-64.qcow2,if=ide -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:36:60 -net user,vlan=0 -m 1024 -smp 1 -drive file=/tmp/kvm_autotest_root/isos/linux/RHEL-5.4-x86_64-DVD.iso,index=2,media=cdrom -fda /usr/local/autotest/tests/kvm/images/floppy.img -tftp /usr/local/autotest/tests/kvm/images/tftpboot -boot d -bootp /pxelinux.0 -boot n -mem-path /mnt/kvm_hugepage -redir tcp:5000::22 -vnc :0 03/04 12:56:13 DEBUG|kvm_subpro:0686| (qemu) kvm_create_vcpu: Bad file descriptor 03/04 12:56:13 DEBUG|kvm_subpro:0686| (qemu) /bin/sh: line 1: 17273 Segmentation fault (core dumped) /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20100304-125508-G6lf,server,nowait -drive file=/tmp/kvm_autotest_root/images/rhel5-64.qcow2,if=ide -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:36:60 -net user,vlan=0 -m 1024 -smp 1 -drive file=/tmp/kvm_autotest_root/isos/linux/RHEL-5.4-x86_64-DVD.iso,index=2,media=cdrom -fda /usr/local/autotest/tests/kvm/images/floppy.img -tftp /usr/local/autotest/tests/kvm/images/tftpboot -boot d -bootp /pxelinux.0 -boot n -mem-path /mnt/kvm_hugepage -redir tcp:5000::22 -vnc :0 03/04 12:56:13 DEBUG|kvm_subpro:0686| (qemu) (Process terminated with status 139) So we have a segmentation fault.

Submitted By: erikvdk
Submitted Date: 2010-03-03 12:20
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: intel
Resolution: None


Dear all, If one runs the following commands after installing qemu-0.12.3 or qemu-kvm-0.12.3: wget http://www.minix3.org/download/minix_R3.1.6-r6084.iso.bz2 bunzip2 minix_R3.1.6-r6084.iso.bz2 qemu-system-x86_64 -cdrom minix_R3.1.6-r6084.iso -enable-kvm and presses 1 (Regular MINIX 3), the following error message results when loading MINIX: kvm: unhandled exit 80000021 kvm_run returned -22 The guest stops after that. This error message does not occur without the -enable-kvm switch. It does not occur with qemu-kvm-0.11.0 as bundled with Ubuntu. The problem occurs with the "qemu" binary from qemu-0.12.3 as well as "qemu-system-x86_64" from qemu-kvm-0.12.3, but in the former case no error message is printed. The code that is running when it fails is in https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fsrc%2Fboot%2Fboothead.s&revision=5918&view=markup. It happens in ext_copy: ext_copy: mov x_dst_desc+2, ax movb x_dst_desc+4, dl ! Set base of destination segment mov ax, 8(bp) mov dx, 10(bp) mov x_src_desc+2, ax movb x_src_desc+4, dl ! Set base of source segment mov si, #x_gdt ! es:si = global descriptor table shr cx, #1 ! Words to move movb ah, #0x87 ! Code for extended memory move int 0x15 The line that fails is "int 0x15", which performs a BIOS call to copy data from low memory to above the 1MB barrier. The machine is running in 16-bit real mode when this code is executed. Output for "uname -a" on the host: Linux hp364 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux Output for "cat /proc/cpuinfo" on the host: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz stepping : 10 cpu MHz : 1998.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 6650.50 clflush size : 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz stepping : 10 cpu MHz : 1998.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 6649.80 clflush size : 64 power management: With kind regards, Erik

Submitted By: iggy_cav
Submitted Date: 2010-03-01 17:56
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: None
Resolution: None


I can get the virtio net drivers for Windows to repeatably lock up. I have a Windows 2008 R2 guest that has 3 virtio net connections connected to 3 bridges in the host. One network is for network traffic and two are for a storage network. The storage network interfaces are connecting to an iSCSI appliance. When syncing files from another server on the network (reading on interface 0, writing to iSCSI target on interfaces 1 & 2), the interfaces stop passing traffic for a period of time. It does eventually recover and is able to send/recv traffic. This causes the iSCSI volumes to be dropped and the guest subsequently gets into such a bad shape that it has to be rebooted. This is using self built virtio drivers from a git checkout on 20100226 Using qemu-kvm also from 20100226 (which does include a fix for a bug that I used to hit where the network would break and never come back) Let me know if you need any other info.

Submitted By: zsalwasser
Submitted Date: 2010-02-27 20:09
Assigned To: Nobody/Anonymous

Status: Closed
Priority: 5
Category: kernel
Resolution: None


cpu vendor type: vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz stepping : 5 cpu MHz : 1999.713 cache size : 4096 KB (8 cores) host distribution: Debian 5 stable Linux iQCortex-2 2.6.32-2-686-bigmem #1 SMP Thu Feb 11 04:55:32 UTC 2010 i686 GNU/Linux versions: Linux 2.6.32-8 kvm-kmod 2.6.32.8 qemu-kvm 0.12.2 bitness: 32 (PAE enabled host) guest: 32 bit Windows XP SP3, no PAE I have been having trouble with reading the extended registers normally read by kvm_get_sregs() on host kernels ~2.6.32 and higher. I am currently running Linux 2.6.32-8, kvm-kmod 2.6.32.8, and qemu 0.12.2. I get the following output when I try info registers on the qemu console: (qemu) info registers EAX=6d63c93d EBX=ffdffc70 ECX=ffdffc70 EDX=00000000 ESI=ffdffc50 EDI=823e7b68 EBP=80550f50 ESP=80550f34 EIP=f8621d3e EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =3d65 00001000 b772bdf8 3fffe800 DPL=3 Reserved CS =4fe1 b7d59ff4 b7d5b3a0 6b300100 SS =0000 b772bde8 0847ab38 6f300a00 DS =b3d0 b7d5b3cc 00000000 7bffd500 DPL=2 DS [E-A] FS =e008 b7d5b3a0 b7d59ff4 005bb900 DPL=1 CS32 [--A] GS =ffff ffffffff 00000007 7fffff00 DPL=3 CS64 [CRA] LDT=9ff4 b772bde0 00000008 7ffff500 DPL=3 DS [E-A] TR =0000 00000080 b7fb63ab 00f00000 GDT= 00014fe1 00000100 IDT= b7d5b3cc 0000b3d0 CR0=08000101 CR2=00002000 CR3=00000000 CR4=08000101 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000000 FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00000000 FPR0=0000000000000000 ffff FPR1=00ff00ff00ff00ff ffff FPR2=0000000000000000 ffff FPR3=00fe000d009900ee ffff FPR4=ff0d9aefff6a604c ffff FPR5=00ff000d009a00ef ffff FPR6=0000000000000000 ffff FPR7=0080008000800080 ffff XMM00= 00000020000000000000000000000001 XMM01=81181ab88055f980e115d00000000020 XMM02=f79092a481181ab8c03845740dd1d000 XMM03=81181ab8c03845740000016d804e93e0 XMM04=c0384574000000000000000100000000 XMM05=e1150000804e7e36f790931400000000 XMM06=806f02980000000000000000c0384574 XMM07=000000028055f62000000080c0384574 Note that cr3 is 0, which doesn't seem possible. The contents of the sregs is also static across invocations of info registers (whereas the "regs" chang), indicating that the values that are there are garbage. Delving deeper, when I check actual invocations of kvm_get_sregs(), it usually returns either 0 or -22, neither value indicating success. I added some debug output to kvm-all.c and obtained the following example states for kvm_get_regs (which works) and kvm_get_sregs (which doesn't): (kvm_get_regs): kvm_vcpu_ioctl = 0x808ccad 1: (kvm_vcpu_ioctl/KVM_GET_REGS): kvm_vcpu_ioctl = 0x808ccad 2: (kvm_vcpu_ioctl/KVM_GET_REGS): ioctl = 0x8069134, env->kvm_fd = 13, type = -2138001791, arg = 0xb532afb8 3: (kvm_vcpu_ioctl/KVM_GET_REGS): ret = 0, errno = 4 (Interrupted system call) (kvm_get_sregs): kvm_vcpu_ioctl = 0x808ccad 1: (kvm_vcpu_ioctl/KVM_GET_SREGS): kvm_vcpu_ioctl = 0x808ccad 2: (kvm_vcpu_ioctl/KVM_GET_SREGS): ioctl = 0x8069134, env->kvm_fd = 13, type = -2126991741, arg = 0xb532ace0 3: (kvm_vcpu_ioctl/KVM_GET_SREGS): ret = -1, errno = 22 (Invalid argument) Basically, it seems like the ioctl never comes out the other side of glibc. Ordinarily, the call goes something like this: kvm_get_sregs->kvm_vcpu_ioctl(kvm-all.c:1950)->ioctl(glibc)->kvm_vcpu_ioctl(kvm_main.c:1930)->kvm_arch_vcpu_ioctl_get_sregs(?) But the call never gets to kvm_vcpu_ioctl(kvm_main.c:1930), because glibc appears to be rejecting the call to ioctl for having an invalid argument. I've got if (ioctl == KVM_GET_SREGS) { printk(KERN_INFO "ZTS: ioctl == KVM_GET_SREGS (%x)\n", ioctl); } In kvm_vcpu_ioctl(kvm_main.c:1930) and I never see that message printed on dmesg, so I know that kvm_vcpu_ioctl(kvm_main.c:1930) is never being called with KVM_GET_SREGS as an argument.

Submitted By:
Submitted Date: 2010-02-16 21:19
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: None
Resolution: None


OpenSolaris 2009.06 downloaded from opensolaris.org (osol-0906-x86.iso) breaks on boot with qemu-kvm-0.12.2: I am running AMD Athlon(tm) 64 X2 Dual-Core Processor TK-57 in 32bit environment. Linux buzz 2.6.32-13-generic #18-Ubuntu SMP Wed Feb 10 21:24:20 UTC 2010 i686 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu lucid (development branch) Release: 10.04 Codename: lucid This is happening with -cpu set to qemu64, phenom, core2duo, kvm64, qemu64, coreduo, 486, pentium2, pentium3, athlon and n270. This gets printed to the terninal: BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters kvm: unhandled exit ffffffff kvm_run returned -22 It works with qemu32 and pentium cpus.

Submitted By: djgera
Submitted Date: 2010-02-12 04:29
Assigned To: Nobody/Anonymous

Status: Open
Priority: 5
Category: amd
Resolution: None


KVM Version: 0.12.2 Host: Linux 2.6.32.8 (tested in 32 and 64 bits) [Arch Linux] Guest: Linux-2.6.32.8/2.6.27.45 (tested in 32 and 64 bits) [Arch Linux] CPU: AMD 64 X2 5200+ What works: * Using in default KVM mode. * Using QEMU 0.12.2, without KVM mode. * Doing a halt, guest poweroff without any issues in all configurations. Steps: * qemu-system-x86_64 -no-kvm archlinux.img * reboot (guest) Symptoms: * kernel stop on message: "machine restart". * At this point, on monitor doing a system_reset/system_poweroff does not restart/poweroff (just blank main screen) If you need more info, please ask me. Thanks.