Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
Hi Jan, I still need assistance on my problem. Please have a look at the trace files and send me some hints to look for in the next step. Thanks. Best regards, Erik Erik Rull wrote: Hi all, I'm still stuck at the same point - I would like to proceed my work but I need assistance by getting an evaluation result on the trace files I posted. It's getting a bit more time critical now on my side, because updates for ~ 100 systems worldwide have to be rolled out within the next weeks... Thanks a lot. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
Erik Rull wrote: On September 12, 2014 at 7:29 PM Jan Kiszka wrote: On 2014-09-12 19:15, Jan Kiszka wrote: On 2014-09-12 14:29, Erik Rull wrote: On September 11, 2014 at 3:32 PM Jan Kiszka wrote: On 2014-09-11 15:25, Erik Rull wrote: On August 6, 2014 at 1:19 PM Erik Rull wrote: Hi all, I did already several tests and I'm not completely sure what's going wrong, but here my scenario: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works, too. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Any hint what to change / test would be really appreciated. Thanks in advance, Best regards, Erik Hi all, I opened a qemu bug report on that and Jan helped me creating a kvm trace. I attached it to the bug report. https://bugs.launchpad.net/qemu/+bug/1366836 If you have further questions, please let me know. "File possibly truncated. Need at least 346583040, but file size is 133414912." Does "trace-cmd report" work for you? Is your file larger? Again, please also validate the behavior on latest next branch from kvm.git. Jan Hi all, confirmed. The issue is still existing in the kvm.git Version of the kernel. The trace.tgz was uploaded to the bugtracker. Thanks. Could you provide a good-case of your setup as well, i.e. with that older kernel version? At least I'm not yet seeing something obviously wrong. Well, except that we have continuously EXTERNAL_INTERRUPTs, vector 0xf6, throughout most of the trace. Maybe a self-IPI (this is single-core), maybe something external that is stuck. You could do a full trace (-e all) and check for what happens after things like kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8168ed83 info 0 80ef Jan The huge number of interrupts seem to be rescheduling interrupts from qemu/kvm. I disabled SMP (kernel cmdline "nosmp") and retried - same effect, Windows 8 does not boot. But I was able to get rid of the reschedulding interrupts. The trace after / around a kvm_exit looks like this: qemu-system-x86-954 [001] 261013.227405: kvm_entry:vcpu 0 qemu-system-x86-952 [000] 261013.227405: kmem_cache_free: call_site=c10ef001 ptr=0xf1d2ae48 qemu-system-x86-952 [000] 261013.227406: mm_filemap_delete_from_page_cache: dev 0:3 ino 0 page=0xf5bcc9c0 pfn=4122790336 ofs=507641856 qemu-system-x86-952 [000] 261013.227406: kmem_cache_free: call_site=c10ef001 ptr=0xf1d2ae10 qemu-system-x86-952 [000] 261013.227406: mm_filemap_delete_from_page_cache: dev 0:3 ino 0 page=0xf5bcc9e0 pfn=4122790368 ofs=507645952 qemu-system-x86-954 [001] 261013.227406: kvm_exit: reason EXCEPTION_NMI rip 0x812a1d83 info 80201120 8b0e qemu-system-x86-954 [001] 261013.227407: kvm_page_fault: address 80201120 error_code 3 qemu-system-x86-952 [000] 261013.227407: mm_page_free_batched: page=0xf5bcc9e0 pfn=4122790368 order=0 cold=0 qemu-system-x86-954 [001] 261013.227407: kvm_mmu_pagetable_walk: addr 80201120 pferr 3 P|W qemu-system-x86-952 [000] 261013.227407: mm_page_free: page=0xf5bcc9e0 pfn=4122790368 order=0 qemu-system-x86-954 [001] 261013.227407: kvm_mmu_paging_element: pte 188001 level 3 qemu-system-x86-952 [000] 261013.227407: mm_page_free_batched: page=0xf5bcc9c0 pfn=4122790336 order=0 cold=0 qemu-system-x86-954 [001] 261013.227407: kvm_mmu_paging_element: pte 39b863 level 2 or qemu-system-x86-954 [001] 261013.276282: kvm_mmu_paging_element: pte 188001 level 3 qemu-system-x86-954 [001] 261013.276283: kvm_mmu_paging_element: pte 39b863 level 2 qemu-system-x86-954 [001] 261013.276283: kvm_mmu_paging_element: pte 80188963 level 1 qemu-system-x86-954 [001] 261013.276284: rcu_utilization: Start context switch qemu-system-x86-954 [001] 261013.276284: rcu_utilization: End context switch qemu-system-x86-954 [001] 261013.276284: kvm_entry:vcpu 0 qemu-system-x86-954 [001] 261013.276285: kvm_exit: reason EXCEPTION_NMI rip 0x812a1d83 info 80201120 8b0e qemu-system-x86-954 [001] 261013.276286: kvm_page_fault: address 80201120 error_code 3 qemu-system-x86-954 [001] 261013.276286: kvm_mmu_pagetable_walk: addr 80201120 pferr 3 P|W qemu-system-x86-954 [001] 261013.276286: kvm_mmu_paging_element: pte 188001 level 3 qemu-system-x86-954 [001] 261013.276287: kvm_mmu_paging_element: pte 39b863 level 2 qemu-system-x86
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On September 12, 2014 at 7:29 PM Jan Kiszka wrote: > > > On 2014-09-12 19:15, Jan Kiszka wrote: > > On 2014-09-12 14:29, Erik Rull wrote: > >>> On September 11, 2014 at 3:32 PM Jan Kiszka > >>> wrote: > >>> > >>> > >>> On 2014-09-11 15:25, Erik Rull wrote: > >>>>> On August 6, 2014 at 1:19 PM Erik Rull wrote: > >>>>> > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I did already several tests and I'm not completely sure what's going > >>>>> wrong, > >>>>> but > >>>>> here my scenario: > >>>>> > >>>>> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a > >>>>> vanilla > >>>>> kernel > >>>>> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any > >>>>> error. > >>>>> When I dump the CPU registers via "info registers", nothing changes, > >>>>> that > >>>>> means > >>>>> the system really stalled. Same happens with QEMU 2.0.0. > >>>>> > >>>>> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU > >>>>> 1.7.0 > >>>>> on > >>>>> the host side it works on the Core2Duo. Also the system above but just > >>>>> with > >>>>> an > >>>>> i3 or i5 CPU it works, too. > >>>>> > >>>>> I already disabled networking and USB for the guest and changed the > >>>>> graphics > >>>>> card - no effect. I assume that some mean bits and bytes have to be set > >>>>> up > >>>>> properly to get the thing running. > >>>>> > >>>>> Any hint what to change / test would be really appreciated. > >>>>> > >>>>> Thanks in advance, > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Erik > >>>>> > >>>> > >>>> Hi all, > >>>> > >>>> I opened a qemu bug report on that and Jan helped me creating a kvm > >>>> trace. I > >>>> attached it to the bug report. > >>>> https://bugs.launchpad.net/qemu/+bug/1366836 > >>>> > >>>> If you have further questions, please let me know. > >>> > >>> "File possibly truncated. Need at least 346583040, but file size is > >>> 133414912." > >>> > >>> Does "trace-cmd report" work for you? Is your file larger? > >>> > >>> Again, please also validate the behavior on latest next branch from > >>> kvm.git. > >>> > >>> Jan > >>> > >> > >> Hi all, > >> > >> confirmed. The issue is still existing in the kvm.git Version of the > >> kernel. > >> The trace.tgz was uploaded to the bugtracker. > > > > Thanks. Could you provide a good-case of your setup as well, i.e. with > > that older kernel version? At least I'm not yet seeing something > > obviously wrong. > > Well, except that we have continuously EXTERNAL_INTERRUPTs, vector 0xf6, > throughout most of the trace. Maybe a self-IPI (this is single-core), > maybe something external that is stuck. You could do a full trace (-e > all) and check for what happens after things like > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8168ed83 info 0 80ef > > Jan > The huge number of interrupts seem to be rescheduling interrupts from qemu/kvm. I disabled SMP (kernel cmdline "nosmp") and retried - same effect, Windows 8 does not boot. But I was able to get rid of the reschedulding interrupts. The trace after / around a kvm_exit looks like this: qemu-system-x86-954 [001] 261013.227405: kvm_entry: vcpu 0 qemu-system-x86-952 [000] 261013.227405: kmem_cache_free: call_site=c10ef001 ptr=0xf1d2ae48 qemu-system-x86-952 [000] 261013.227406: mm_filemap_delete_from_page_cache: dev 0:3 ino 0 page=0xf5bcc9c0 pfn=4122790336 ofs=507641856 qemu-system-x86-952 [000] 261013.227406: kmem_cache_free: call_site=c10ef001 ptr=0xf1d2ae10 qemu-system-x86-952 [000] 261013.227406: mm_filemap_delete_from_page_cache: dev 0:3 ino 0 page=0xf5bcc9e0 pfn=4122790368 ofs=507645952 qemu-system-x86-954 [001] 261013.227406: kvm_exit: reason EXCEPTION_NMI rip 0x812a1d83 info 80201120 8b0e q
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On September 15, 2014 at 12:48 PM Erik Rull wrote: > > > > On September 12, 2014 at 7:29 PM Jan Kiszka wrote: > > > > > > On 2014-09-12 19:15, Jan Kiszka wrote: > > > On 2014-09-12 14:29, Erik Rull wrote: > > >>> On September 11, 2014 at 3:32 PM Jan Kiszka > > >>> wrote: > > >>> > > >>> > > >>> On 2014-09-11 15:25, Erik Rull wrote: > > >>>>> On August 6, 2014 at 1:19 PM Erik Rull > > >>>>> wrote: > > >>>>> > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> I did already several tests and I'm not completely sure what's going > > >>>>> wrong, > > >>>>> but > > >>>>> here my scenario: > > >>>>> > > >>>>> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a > > >>>>> vanilla > > >>>>> kernel > > >>>>> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without > > >>>>> any > > >>>>> error. > > >>>>> When I dump the CPU registers via "info registers", nothing changes, > > >>>>> that > > >>>>> means > > >>>>> the system really stalled. Same happens with QEMU 2.0.0. > > >>>>> > > >>>>> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU > > >>>>> 1.7.0 > > >>>>> on > > >>>>> the host side it works on the Core2Duo. Also the system above but just > > >>>>> with > > >>>>> an > > >>>>> i3 or i5 CPU it works, too. > > >>>>> > > >>>>> I already disabled networking and USB for the guest and changed the > > >>>>> graphics > > >>>>> card - no effect. I assume that some mean bits and bytes have to be > > >>>>> set > > >>>>> up > > >>>>> properly to get the thing running. > > >>>>> > > >>>>> Any hint what to change / test would be really appreciated. > > >>>>> > > >>>>> Thanks in advance, > > >>>>> > > >>>>> Best regards, > > >>>>> > > >>>>> Erik > > >>>>> > > >>>> > > >>>> Hi all, > > >>>> > > >>>> I opened a qemu bug report on that and Jan helped me creating a kvm > > >>>> trace. I > > >>>> attached it to the bug report. > > >>>> https://bugs.launchpad.net/qemu/+bug/1366836 > > >>>> > > >>>> If you have further questions, please let me know. > > >>> > > >>> "File possibly truncated. Need at least 346583040, but file size is > > >>> 133414912." > > >>> > > >>> Does "trace-cmd report" work for you? Is your file larger? > > >>> > > >>> Again, please also validate the behavior on latest next branch from > > >>> kvm.git. > > >>> > > >>> Jan > > >>> > > >> > > >> Hi all, > > >> > > >> confirmed. The issue is still existing in the kvm.git Version of the > > >> kernel. > > >> The trace.tgz was uploaded to the bugtracker. > > > > > > Thanks. Could you provide a good-case of your setup as well, i.e. with > > > that older kernel version? At least I'm not yet seeing something > > > obviously wrong. > > > > Well, except that we have continuously EXTERNAL_INTERRUPTs, vector 0xf6, > > throughout most of the trace. Maybe a self-IPI (this is single-core), > > maybe something external that is stuck. You could do a full trace (-e > > all) and check for what happens after things like > > > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8168ed83 info 0 80ef > > > > Jan > > > > I captured the trace log (-e all) and uploaded it to the bug tracker. I was > not > yet able to get trace-cmd running for my old 2.6.32.12 kernel, as soon as I > get > it working, I'll send the -e all trace. > > Best regards, > > Erik The splice command is not available before glibc-2.5 in userspace, but my old system runs on glibc-2.3.6, so trace-cmd will never compile and run there, sorry :-( Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On September 12, 2014 at 7:29 PM Jan Kiszka wrote: > > > On 2014-09-12 19:15, Jan Kiszka wrote: > > On 2014-09-12 14:29, Erik Rull wrote: > >>> On September 11, 2014 at 3:32 PM Jan Kiszka > >>> wrote: > >>> > >>> > >>> On 2014-09-11 15:25, Erik Rull wrote: > >>>>> On August 6, 2014 at 1:19 PM Erik Rull wrote: > >>>>> > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I did already several tests and I'm not completely sure what's going > >>>>> wrong, > >>>>> but > >>>>> here my scenario: > >>>>> > >>>>> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a > >>>>> vanilla > >>>>> kernel > >>>>> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any > >>>>> error. > >>>>> When I dump the CPU registers via "info registers", nothing changes, > >>>>> that > >>>>> means > >>>>> the system really stalled. Same happens with QEMU 2.0.0. > >>>>> > >>>>> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU > >>>>> 1.7.0 > >>>>> on > >>>>> the host side it works on the Core2Duo. Also the system above but just > >>>>> with > >>>>> an > >>>>> i3 or i5 CPU it works, too. > >>>>> > >>>>> I already disabled networking and USB for the guest and changed the > >>>>> graphics > >>>>> card - no effect. I assume that some mean bits and bytes have to be set > >>>>> up > >>>>> properly to get the thing running. > >>>>> > >>>>> Any hint what to change / test would be really appreciated. > >>>>> > >>>>> Thanks in advance, > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Erik > >>>>> > >>>> > >>>> Hi all, > >>>> > >>>> I opened a qemu bug report on that and Jan helped me creating a kvm > >>>> trace. I > >>>> attached it to the bug report. > >>>> https://bugs.launchpad.net/qemu/+bug/1366836 > >>>> > >>>> If you have further questions, please let me know. > >>> > >>> "File possibly truncated. Need at least 346583040, but file size is > >>> 133414912." > >>> > >>> Does "trace-cmd report" work for you? Is your file larger? > >>> > >>> Again, please also validate the behavior on latest next branch from > >>> kvm.git. > >>> > >>> Jan > >>> > >> > >> Hi all, > >> > >> confirmed. The issue is still existing in the kvm.git Version of the > >> kernel. > >> The trace.tgz was uploaded to the bugtracker. > > > > Thanks. Could you provide a good-case of your setup as well, i.e. with > > that older kernel version? At least I'm not yet seeing something > > obviously wrong. > > Well, except that we have continuously EXTERNAL_INTERRUPTs, vector 0xf6, > throughout most of the trace. Maybe a self-IPI (this is single-core), > maybe something external that is stuck. You could do a full trace (-e > all) and check for what happens after things like > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8168ed83 info 0 80ef > > Jan > I captured the trace log (-e all) and uploaded it to the bug tracker. I was not yet able to get trace-cmd running for my old 2.6.32.12 kernel, as soon as I get it working, I'll send the -e all trace. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On September 11, 2014 at 3:32 PM Jan Kiszka wrote: > > > On 2014-09-11 15:25, Erik Rull wrote: > >> On August 6, 2014 at 1:19 PM Erik Rull wrote: > >> > >> > >> Hi all, > >> > >> I did already several tests and I'm not completely sure what's going wrong, > >> but > >> here my scenario: > >> > >> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla > >> kernel > >> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any > >> error. > >> When I dump the CPU registers via "info registers", nothing changes, that > >> means > >> the system really stalled. Same happens with QEMU 2.0.0. > >> > >> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 > >> on > >> the host side it works on the Core2Duo. Also the system above but just with > >> an > >> i3 or i5 CPU it works, too. > >> > >> I already disabled networking and USB for the guest and changed the > >> graphics > >> card - no effect. I assume that some mean bits and bytes have to be set up > >> properly to get the thing running. > >> > >> Any hint what to change / test would be really appreciated. > >> > >> Thanks in advance, > >> > >> Best regards, > >> > >> Erik > >> > > > > Hi all, > > > > I opened a qemu bug report on that and Jan helped me creating a kvm trace. I > > attached it to the bug report. > > https://bugs.launchpad.net/qemu/+bug/1366836 > > > > If you have further questions, please let me know. > > "File possibly truncated. Need at least 346583040, but file size is > 133414912." > > Does "trace-cmd report" work for you? Is your file larger? > > Again, please also validate the behavior on latest next branch from kvm.git. > > Jan > Hi all, confirmed. The issue is still existing in the kvm.git Version of the kernel. The trace.tgz was uploaded to the bugtracker. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On September 11, 2014 at 3:32 PM Jan Kiszka wrote: > > > On 2014-09-11 15:25, Erik Rull wrote: > >> On August 6, 2014 at 1:19 PM Erik Rull wrote: > >> > >> > >> Hi all, > >> > >> I did already several tests and I'm not completely sure what's going wrong, > >> but > >> here my scenario: > >> > >> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla > >> kernel > >> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any > >> error. > >> When I dump the CPU registers via "info registers", nothing changes, that > >> means > >> the system really stalled. Same happens with QEMU 2.0.0. > >> > >> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 > >> on > >> the host side it works on the Core2Duo. Also the system above but just with > >> an > >> i3 or i5 CPU it works, too. > >> > >> I already disabled networking and USB for the guest and changed the > >> graphics > >> card - no effect. I assume that some mean bits and bytes have to be set up > >> properly to get the thing running. > >> > >> Any hint what to change / test would be really appreciated. > >> > >> Thanks in advance, > >> > >> Best regards, > >> > >> Erik > >> > > > > Hi all, > > > > I opened a qemu bug report on that and Jan helped me creating a kvm trace. I > > attached it to the bug report. > > https://bugs.launchpad.net/qemu/+bug/1366836 > > > > If you have further questions, please let me know. > > "File possibly truncated. Need at least 346583040, but file size is > 133414912." > > Does "trace-cmd report" work for you? Is your file larger? > > Again, please also validate the behavior on latest next branch from kvm.git. > > Jan > Sorry for the corrupt file, didn't work on my side as well. I re-captured the trace (trace-cmd report worked!) and posted it on the bugtracker. The kvm.git test is in progress, my build system is already busy. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
> On August 6, 2014 at 1:19 PM Erik Rull wrote: > > > Hi all, > > I did already several tests and I'm not completely sure what's going wrong, > but > here my scenario: > > When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla > kernel > 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any > error. > When I dump the CPU registers via "info registers", nothing changes, that > means > the system really stalled. Same happens with QEMU 2.0.0. > > But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on > the host side it works on the Core2Duo. Also the system above but just with an > i3 or i5 CPU it works, too. > > I already disabled networking and USB for the guest and changed the graphics > card - no effect. I assume that some mean bits and bytes have to be set up > properly to get the thing running. > > Any hint what to change / test would be really appreciated. > > Thanks in advance, > > Best regards, > > Erik > Hi all, I opened a qemu bug report on that and Jan helped me creating a kvm trace. I attached it to the bug report. https://bugs.launchpad.net/qemu/+bug/1366836 If you have further questions, please let me know. Thanks. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
Hi all, I did already several tests and I'm not completely sure what's going wrong, but here my scenario: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works, too. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Any hint what to change / test would be really appreciated. Thanks in advance, Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Current differences between qemu --enable-kvm and qemu-kvm?
Hi all, is there a summary existing that shows up the rough or actual differences between qemu --enable-kvm and qemu-kvm? I tested both versions with the same compile and start options, the CPU performance results are identical, only the bootup time of my guest system with qemu-kvm seemed to be a bit faster (not measured, it just feeled so). Thanks. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 2, 2012 at 2:21 PM Jan Kiszka wrote: > On 2012-02-02 14:18, Erik Rull wrote: > > > > On February 1, 2012 at 11:05 PM Erik Rull wrote: > > > >> Jan Kiszka wrote: > >>> On 2012-02-01 13:52, Erik Rull wrote: > >>>> Hi all, > >>>> > >>>> first of all I'm a bit confused: > >>>> > >>>> What is the difference between qemu with command line option > > --enable-kvm > >>>> and qemu-kvm? > >>>> It seems to be a difference in code so far, from the performance point > > of > >>>> view it seems to be the same... > >>>> > >>>> Now my issue that lead me to a git bisect on qemu-kvm: > >>>> The following commit / merge breaks my windows guest boot sequence and > >>>> causes resets infinitely: > >>> > >>> Cannot confirm yet, but I have no ACPI-free Windows installation at > >>> hand. Where does it reset, after the BIOS? > >>> > >>>> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' > > into > >>>> next > >>>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi > > Kivity > >>>> > >>>> > >>>> Interesting: qemu with --enable-kvm master and the same command line > >>>> options as qemu-kvm runs perfect. > >>>> My command line options are: > >>>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > > /etc/ich9-ehci-uhci.cfg > >>>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > > /usr/X11R6/share/qemu > >>>> -boot c -localtime > >>> > >>> Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you > >>> try? Does leaving out options change the picture? > >>> > >>> Jan > >>> > >> > >> It happens directly after the windows boot progress bar is completed (I > >> boot without logo) > >> > >> With the -no-kvm-irqchip it seems to be fine... > >> > >> Best regards, > >> > >> Erik > > > > > > Hi Jan, > > > > I tested with an ACPI-enabled windows. > > Results: > > -no-acpi: Continuous reboots like the no-acpi-windows-version > > without -no-acpi: boots! > > > > So I tested the no-acpi-windows-version without -no-acpi option - still > > rebooting > > And without -no-acpi and -no-kvm-irqchip => works again > > Interesting. Need to install such a version, I guess. > > What about no-acpi-windows and upstream qemu with kvm and -machine > kernel_irqchip=on? > > Jan Boots with and without -no-acpi Best regards, Erik P.S. Too many options for me :-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 11:05 PM Erik Rull wrote: > Jan Kiszka wrote: > > On 2012-02-01 13:52, Erik Rull wrote: > >> Hi all, > >> > >> first of all I'm a bit confused: > >> > >> What is the difference between qemu with command line option --enable-kvm > >> and qemu-kvm? > >> It seems to be a difference in code so far, from the performance point of > >> view it seems to be the same... > >> > >> Now my issue that lead me to a git bisect on qemu-kvm: > >> The following commit / merge breaks my windows guest boot sequence and > >> causes resets infinitely: > > > > Cannot confirm yet, but I have no ACPI-free Windows installation at > > hand. Where does it reset, after the BIOS? > > > >> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into > >> next > >> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > >> > >> > >> Interesting: qemu with --enable-kvm master and the same command line > >> options as qemu-kvm runs perfect. > >> My command line options are: > >> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg > >> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu > >> -boot c -localtime > > > > Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you > > try? Does leaving out options change the picture? > > > > Jan > > > > It happens directly after the windows boot progress bar is completed (I > boot without logo) > > With the -no-kvm-irqchip it seems to be fine... > > Best regards, > > Erik Hi Jan, I tested with an ACPI-enabled windows. Results: -no-acpi: Continuous reboots like the no-acpi-windows-version without -no-acpi: boots! So I tested the no-acpi-windows-version without -no-acpi option - still rebooting And without -no-acpi and -no-kvm-irqchip => works again Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
Jan Kiszka wrote: On 2012-02-01 13:52, Erik Rull wrote: Hi all, first of all I'm a bit confused: What is the difference between qemu with command line option --enable-kvm and qemu-kvm? It seems to be a difference in code so far, from the performance point of view it seems to be the same... Now my issue that lead me to a git bisect on qemu-kvm: The following commit / merge breaks my windows guest boot sequence and causes resets infinitely: Cannot confirm yet, but I have no ACPI-free Windows installation at hand. Where does it reset, after the BIOS? ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into next Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity Interesting: qemu with --enable-kvm master and the same command line options as qemu-kvm runs perfect. My command line options are: qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you try? Does leaving out options change the picture? Jan It happens directly after the windows boot progress bar is completed (I boot without logo) With the -no-kvm-irqchip it seems to be fine... Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 5:01 PM Jan Kiszka wrote: > On 2012-02-01 16:43, Erik Rull wrote: > > On February 1, 2012 at 3:42 PM Jan Kiszka wrote: > > > >> On 2012-02-01 15:02, Erik Rull wrote: > >>> > >>> On February 1, 2012 at 2:40 PM Avi Kivity wrote: > >>> > >>>> On 02/01/2012 02:52 PM, Erik Rull wrote: > >>>>> Hi all, > >>>>> > >>>>> first of all I'm a bit confused: > >>>>> > >>>>> What is the difference between qemu with command line option > >>> --enable-kvm > >>>>> and qemu-kvm? > >>>>> It seems to be a difference in code so far, from the performance > > point > >>> of > >>>>> view it seems to be the same... > >>>> > >>>> The differences are being reduced rapidly, thanks to Jan's efforts. > >>>> Right now what remains is PIT performance and accuracy, device > >>>> assignment, and Windows XP performance. Most guests should see the > > same > >>>> performance. > >> > >> MSI performance is expected to be worse with upstream as well, thus > > virtio. > >> > >>>> > >>>>> Now my issue that lead me to a git bisect on qemu-kvm: > >>>>> The following commit / merge breaks my windows guest boot sequence > > and > >>>>> causes resets infinitely: > >>>>> ec757c67c40a56492001487e69272f62144fd124 Merge branch > > 'upstream-merge' > >>> into > >>>>> next > > So commit aad3b517a1b83561f2755dc4451596a421399c19, i.e. the last merge > before that one is still fine? > > >>>>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > >>> > >>>>> > >>>>> > >>>>> Interesting: qemu with --enable-kvm master and the same command line > >>>>> options as qemu-kvm runs perfect. > >>>>> My command line options are: > >>>>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > >>> /etc/ich9-ehci-uhci.cfg > >>>>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>>>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>>>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > >>> /usr/X11R6/share/qemu > >>>>> -boot c -localtime > >>>>> > >>>>> > >>>> > >>>> What version of Windows are you using? What's the contents of > >>>> /etc/ich9-ehci-uhci.cfg? > >>>> > >>> > >>> Hi Avi, > >>> > >>> the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg > >>> > >>> I tried two versions of Windows XP: One is the default Windows XP SP3 > > that > >>> you get from MSDN, one is Windows Embedded Standard (embedded > > customized > >>> XP). > >>> > >>> Both show the same behavior: boots with qemu -enable-kvm and > > continuously > >>> reboots with qemu-kvm. > >> > >> What does qemu-kvm with -no-kvm-irqchip do? > >> > >> Jan > >> > > > > Wow - that works! > > Does this influence the guest performance? > > > > Yes, how much depends on your workload. > > Still strange, though. We should try to understand this issue. It stays > like this up to and including current qemu-kvm.git master? > > Jan > Hi Jan, I didn't follow the branch, only the master between 1.0 and head. Here my bisect log: git bisect start # good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into next git bisect good 30c044521889195f54a9f2c21310894f545994e8 # bad: [2793248c5427c0bc585fdf9c101680bab29f4839] Merge remote-tracking branch 'upstream' into next git bisect bad 2793248c5427c0bc585fdf9c101680bab29f4839 # good: [262db38871b9a2613761cc5f05c4cf697e246a68] qemu-nbd: asynchronous operation git bisect good 262db38871b9a2613761cc5f05c4cf697e246a68 # good: [9737383beb515a583fdb6f2aafa631fcd6797068] qerror: add check-qerror.sh to verify alphabetical order git bisect good 9737383beb515a583fdb6f2aafa631fcd6797068 # skip: [fb5458cd10a199e55e622a906b24f8085d922c0f] qmp: add query-block-jobs git bisect skip fb5458cd10a199e55e622a906b24f8085d922c0f # skip: [aa398a5c3a4c0fc29baf02aee5283a7fa0f202a3] blockdev: make image streaming safe across hotplug git bisect skip aa398a5c3a4c0fc29baf02aee5283a7fa0f202a3 # good: [506b7ddf8
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 3:42 PM Jan Kiszka wrote: > On 2012-02-01 15:02, Erik Rull wrote: > > > > On February 1, 2012 at 2:40 PM Avi Kivity wrote: > > > >> On 02/01/2012 02:52 PM, Erik Rull wrote: > >>> Hi all, > >>> > >>> first of all I'm a bit confused: > >>> > >>> What is the difference between qemu with command line option > > --enable-kvm > >>> and qemu-kvm? > >>> It seems to be a difference in code so far, from the performance point > > of > >>> view it seems to be the same... > >> > >> The differences are being reduced rapidly, thanks to Jan's efforts. > >> Right now what remains is PIT performance and accuracy, device > >> assignment, and Windows XP performance. Most guests should see the same > >> performance. > > MSI performance is expected to be worse with upstream as well, thus virtio. > > >> > >>> Now my issue that lead me to a git bisect on qemu-kvm: > >>> The following commit / merge breaks my windows guest boot sequence and > >>> causes resets infinitely: > >>> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' > > into > >>> next > >>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > > > >>> > >>> > >>> Interesting: qemu with --enable-kvm master and the same command line > >>> options as qemu-kvm runs perfect. > >>> My command line options are: > >>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > > /etc/ich9-ehci-uhci.cfg > >>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > > /usr/X11R6/share/qemu > >>> -boot c -localtime > >>> > >>> > >> > >> What version of Windows are you using? What's the contents of > >> /etc/ich9-ehci-uhci.cfg? > >> > > > > Hi Avi, > > > > the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg > > > > I tried two versions of Windows XP: One is the default Windows XP SP3 that > > you get from MSDN, one is Windows Embedded Standard (embedded customized > > XP). > > > > Both show the same behavior: boots with qemu -enable-kvm and continuously > > reboots with qemu-kvm. > > What does qemu-kvm with -no-kvm-irqchip do? > > Jan > Wow - that works! Does this influence the guest performance? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 2:40 PM Avi Kivity wrote: > On 02/01/2012 02:52 PM, Erik Rull wrote: > > Hi all, > > > > first of all I'm a bit confused: > > > > What is the difference between qemu with command line option --enable-kvm > > and qemu-kvm? > > It seems to be a difference in code so far, from the performance point of > > view it seems to be the same... > > The differences are being reduced rapidly, thanks to Jan's efforts. > Right now what remains is PIT performance and accuracy, device > assignment, and Windows XP performance. Most guests should see the same > performance. > > > Now my issue that lead me to a git bisect on qemu-kvm: > > The following commit / merge breaks my windows guest boot sequence and > > causes resets infinitely: > > ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into > > next > > Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > > > > > > Interesting: qemu with --enable-kvm master and the same command line > > options as qemu-kvm runs perfect. > > My command line options are: > > qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg > > -device usb-host,bus=ehci.0 -device usb-tablet -drive > > file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > > tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu > > -boot c -localtime > > > > > > What version of Windows are you using? What's the contents of > /etc/ich9-ehci-uhci.cfg? > Hi Avi, the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg I tried two versions of Windows XP: One is the default Windows XP SP3 that you get from MSDN, one is Windows Embedded Standard (embedded customized XP). Both show the same behavior: boots with qemu -enable-kvm and continuously reboots with qemu-kvm. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
Hi all, first of all I'm a bit confused: What is the difference between qemu with command line option --enable-kvm and qemu-kvm? It seems to be a difference in code so far, from the performance point of view it seems to be the same... Now my issue that lead me to a git bisect on qemu-kvm: The following commit / merge breaks my windows guest boot sequence and causes resets infinitely: ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into next Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity Interesting: qemu with --enable-kvm master and the same command line options as qemu-kvm runs perfect. My command line options are: qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--disable-kvm breaks build of qemu-kvm
Hi all, the current qemu-kvm master does not compile if --disable-kvm is configured (also earlier version fail). It fails here: CCx86_64-softmmu/apic.o /home/erik/qemu-kvm/hw/apic.c: In function 'kvm_irqchip_deliver_nmi': /home/erik/qemu-kvm/hw/apic.c:141: error: storage size of 'klapic' isn't known /home/erik/qemu-kvm/hw/apic.c:144: warning: implicit declaration of function 'kvm_get_lapic' /home/erik/qemu-kvm/hw/apic.c:144: warning: nested extern declaration of 'kvm_get_lapic' /home/erik/qemu-kvm/hw/apic.c:155: error: 'KVM_NMI' undeclared (first use in this function) /home/erik/qemu-kvm/hw/apic.c:155: error: (Each undeclared identifier is reported only once /home/erik/qemu-kvm/hw/apic.c:155: error: for each function it appears in.) /home/erik/qemu-kvm/hw/apic.c:141: warning: unused variable 'klapic' make[1]: *** [apic.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I know that the use case might be a bit weired but either it should compile or the option for disabling should be removed :-) Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous reboots on qemu-kvm master
Marcelo Tosatti wrote: On Mon, Jan 23, 2012 at 05:12:07PM +0100, erik.r...@rdsoftware.de wrote: Hi all, I get continuous reboots on my guest system, including these dmesg entries: [ 31.770538] device tap0 entered promiscuous mode [ 31.770554] br0: port 2(tap0) entering learning state [ 39.259921] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 39.259936] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 39.259946] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 44.870691] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 44.870801] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 44.870901] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 46.727081] br0: port 2(tap0) entering forwarding state [ 50.481469] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 50.481583] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 50.481685] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 55.827950] br0: port 2(tap0) entering disabled state [ 55.828110] device tap0 left promiscuous mode [ 55.828200] br0: port 2(tap0) entering disabled state My ./configure is: ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-card-list= --audio-drv-list= --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-nptl --disable-curl --disable-guest-agent --disable-guest-base --disable-werror --disable-attr My qemu cmdline is: /usr/X11R6/bin/qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1536 -net nic -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm Was fine with qemu-kvm-1.0 and the same options! Best regards, Erik Erik, Can you bisect to find the culprit, please? I will try to do that. Currently I have to find another issue between 0.15.0 and 1.0 :-) After having found that, I will continue bisecting here :-) Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Continuous reboots on qemu-kvm master
Hi all, I get continuous reboots on my guest system, including these dmesg entries: [ 31.770538] device tap0 entered promiscuous mode [ 31.770554] br0: port 2(tap0) entering learning state [ 39.259921] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 39.259936] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 39.259946] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 44.870691] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 44.870801] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 44.870901] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 46.727081] br0: port 2(tap0) entering forwarding state [ 50.481469] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 400080532d74 [ 50.481583] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 50.481685] kvm: 1517: cpu0 unhandled wrmsr: 0x0 data 0 [ 55.827950] br0: port 2(tap0) entering disabled state [ 55.828110] device tap0 left promiscuous mode [ 55.828200] br0: port 2(tap0) entering disabled state My ./configure is: ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-card-list= --audio-drv-list= --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-nptl --disable-curl --disable-guest-agent --disable-guest-base --disable-werror --disable-attr My qemu cmdline is: /usr/X11R6/bin/qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1536 -net nic -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm Was fine with qemu-kvm-1.0 and the same options! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VNC and SDL/VGA simultaneously?
Hi all, is there an update regarding simultaneous use of VNC and VGA output? Thanks. Best regards, Erik Bitman Zhou wrote: We tried before with both spice(QXL) and VNC enabled at the same time for the same VM. It works a little bit, I mean VNC session can hold some time. I use gtk-vnc and it looks like qemu vnc implementation sends some special packets and cause gtk-vnc broken. BR Bitman Zhou 在 2011-03-10四的 20:15 +0100，Erik Rull写道： Avi Kivity wrote: On 03/09/2011 11:31 PM, Erik Rull wrote: Hi all, is it possible to parameterize qemu in a way where the VNC port and the VGA output is available in parallel? Not really, though it should be possible to do it with some effort. My system screen remains dark if I run it with the -vnc :0 option and vnc is unavailable when SDL/VGA is available. What's your use case? I want to make remote support possble for a guest system that has only a local network connection to the host and has a graphical console running where the operator works on. (So "real" VNC is not available to the rest of the world) It would also be okay if a switching between the VNC and the SDL/VGA would be possible at runtime so that the remote support can do the work and then switch back to the operators screen. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CPU assignment possiblities?
Hi all, I want to assign multiple host cores to a VM that are then exposed there as only one virtual processor core. I want to maximize there the available computation power and the guest OS cannot handle SMP. And: How can I enable qemu-kvm to run on multiple host cores? I have a i7 HT enabled system on another server and don't see that the process is running on multiple cores but only on one. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: 0.14.0 -device usb-host supports only one device
When enabling the -device usb-host option support for adding automatically USB devices from the host to the guest, only one device gets detected. It does not matter if it is added via commandline or via device_add on the qemu console. Curious: If a second devices is plugged into the host, nothing happens in qemu. But on the host, the device is detected. If the first device is removed, the second device gets detected by qemu. If then the first device is added again, it gets not detected by qemu until the second device is removed and so on. When adding the devices manually, everything is fine. Confirmed with and without the ehci-patch on qemu-kvm 0.14.0. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm, emulation hangs when using some usb device
slavik wrote: I have some troubles with passing usb into kvm virtual machine. I trying to provide the usb device 2022:0008 (Amikon vpn key) or 19d2:2000 (ZTE MF112 hsdpa modem) into virtual machine with windows xp iax32. kvm virtual machine was hung completely, and stop responding to anything. Maybe I need there some trick to use this kind (switchable?) of usb devices? ps: Linux workdesk 2.6.38-gentoo #1 SMP Mon Mar 21 18:10:13 YEKT 2011 x86_64 AMD Phenom(tm) II X6 1055T Processor AuthenticAMD GNU/Linux Have you enabled USB 2.0 on your host system? If yes -> causes issues (Windows Bluescreen e.g.) with printers and sometimes other USB 2.0 devices. If you set it to USB 1.1, it should be fine but the transfer rate is extremely low. I would propose the ehci-patch from David, this works quite nice and gives a good transfer performance and no bluescreens with printers and so on. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
erik.r...@rdsoftware.de wrote: Hi all, I've tested the following: - EHCI patch without auto_add and adding the devices manually Result: Works fine, all devices could be added. I've tested only 2 but it is more than with the auto_add feature :-) - UHCI only (no EHCI patch) with enabled "-device usb-host" Result: Same as with EHCI-Patch and enabled auto_add! Only ONE device gets detected. info usb shows two (tablet and one hardware usb device) info usbhost shows two hardware devices (+ the complete host controller set), where the second one does not get detected by qemu-kvm until the first device gets removed. If I then plug in again the first device, it does not get detected until the second gets removed (and so on) So the auto-add seems to be buggy in all configurations, it does not seem to be related with the EHCI-patch (that's my thought at this point). Best regards, Erik Has there been a progress or idea how to proceed on the reported things? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
Hi all, I've tested the following: - EHCI patch without auto_add and adding the devices manually Result: Works fine, all devices could be added. I've tested only 2 but it is more than with the auto_add feature :-) - UHCI only (no EHCI patch) with enabled "-device usb-host" Result: Same as with EHCI-Patch and enabled auto_add! Only ONE device gets detected. info usb shows two (tablet and one hardware usb device) info usbhost shows two hardware devices (+ the complete host controller set), where the second one does not get detected by qemu-kvm until the first device gets removed. If I then plug in again the first device, it does not get detected until the second gets removed (and so on) So the auto-add seems to be buggy in all configurations, it does not seem to be related with the EHCI-patch (that's my thought at this point). Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
Markus Armbruster wrote: Erik Rull writes: Markus Armbruster wrote: erik.r...@rdsoftware.de writes: - using -device usb-host causes windows not to boot completely, using -usbdevice host:auto:*.* is fine! - using -usbdevice tablet is better than using -device usb-tablet Better inhowfar? [...] It seems to work fine, the other option caused either windows not to boot fully or the auto grabbing itself doesn't seem to work or the mouse just didn't move. I experienced all of the three, but I haven't noted down in which combinations - sorry. Please provide recipes to reproduce the bugs. - take Windows XP 32 bit SP3 as Guest - apply the ehci patch to qemu-kvm-0.14.0 (David posted it here some days ago) boot the guest using the command line args: -usb -device usb-host (I also tried the proposal where the additonal usb-host options are all set to 0, same result) Windows starts but hangs before the GUI comes up (I boot without logo, so the white bar that comes up when booting stays for > 20 minutes (I aborted afterwards)), the CPU usage on a Core2Duo system goes to ~10-14%. If I use instead -usb -usbdevice host:auto:*.* everything is fine! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
David Ahern wrote: On 03/11/11 08:18, erik.r...@rdsoftware.de wrote: I tested again with your hints, here my results: - using -device usb-host causes windows not to boot completely, using -usbdevice host:auto:*.* is fine! - using -usbdevice tablet is better than using -device usb-tablet - only one "external" USB device gets detected, the rest is just ignored. qemu does not recognize the device, but the host OS sees it (dmesg output) I have not used the auto feature. What happens if you disable it and instead add the devices you want? I have been able to add both a printer and a USB key to a guest -- both on the EHCI bus. And just verified again - both printer and USB key accessible within the guest. I will test that on monday and will let you know about the results. - if the first plugged in device is removed from the usb port and the second (not detected one) is still plugged in, then this second device gets now detected by qemu and is handled to the guest Interesting. Gerd made a lot of changes to the USB code right before 0.14. I have not really followed the change set - or how it might impact ehci. It could be a bug independent of ehci as well -- try it without the ehci patch and see if the same occurs. Very good point :-) I've never tested that because I knew that the USB printer will then crash my guest :-) But I will follow that idea on monday as well. Additionally something really interesting: if I disable USB 2.0 in my host BIOS and boot my guest system with the qemu ehci patch, then I get no longer the BSOD in windows when removing the printer! :-) So the patch seems also to improve the usb-uhci stuff. Our mileage differs here as well. I'm running Fedora 14 on my laptop. With the ehci enabled version of qemu-kvm I have no problems connecting and disconnecting devices -- host or guest. Except the not fully functioning auto add feature we're on the same level, because I've not tested the manual adding (and I assume / hope that it will be successful). David Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
Markus Armbruster wrote: erik.r...@rdsoftware.de writes: Hi David, I did a second iteration and it looked way better, maybe my first attempts were somehow buggy. First - please review your DPRINTF in the usb-ehci.c, there is a variable "dev" undefined in line 504/505 when enabling the debugging defines at the top of the file, the compiler complains there. I tested again with your hints, here my results: - using -device usb-host causes windows not to boot completely, using -usbdevice host:auto:*.* is fine! - using -usbdevice tablet is better than using -device usb-tablet Better inhowfar? [...] It seems to work fine, the other option caused either windows not to boot fully or the auto grabbing itself doesn't seem to work or the mouse just didn't move. I experienced all of the three, but I haven't noted down in which combinations - sorry. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
Hi David, I did a second iteration and it looked way better, maybe my first attempts were somehow buggy. First - please review your DPRINTF in the usb-ehci.c, there is a variable "dev" undefined in line 504/505 when enabling the debugging defines at the top of the file, the compiler complains there. I tested again with your hints, here my results: - using -device usb-host causes windows not to boot completely, using -usbdevice host:auto:*.* is fine! - using -usbdevice tablet is better than using -device usb-tablet - only one "external" USB device gets detected, the rest is just ignored. qemu does not recognize the device, but the host OS sees it (dmesg output) - if the first plugged in device is removed from the usb port and the second (not detected one) is still plugged in, then this second device gets now detected by qemu and is handled to the guest Additionally something really interesting: if I disable USB 2.0 in my host BIOS and boot my guest system with the qemu ehci patch, then I get no longer the BSOD in windows when removing the printer! :-) So the patch seems also to improve the usb-uhci stuff. So everything is fine now beside the "more than one USB device" issue. Any ideas what this could be? Thanks a lot for your support! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VNC and SDL/VGA simultaneously?
Avi Kivity wrote: On 03/09/2011 11:31 PM, Erik Rull wrote: Hi all, is it possible to parameterize qemu in a way where the VNC port and the VGA output is available in parallel? Not really, though it should be possible to do it with some effort. My system screen remains dark if I run it with the -vnc :0 option and vnc is unavailable when SDL/VGA is available. What's your use case? I want to make remote support possble for a guest system that has only a local network connection to the host and has a graphical console running where the operator works on. (So "real" VNC is not available to the rest of the world) It would also be okay if a switching between the VNC and the SDL/VGA would be possible at runtime so that the remote support can do the work and then switch back to the operators screen. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
David Ahern wrote: On 03/09/11 14:28, Erik Rull wrote: David Ahern wrote: I've tried it long time ago with kvm-88, but there it was working but extremely slow. (At least the mouse was reacting there) I thought you tried the EHCI patch against a recent qemu-kvm version -- like December 2010 or January 2011. Yes, this time I patched against 0.14.0, I misunderstood your question, sorry. My last attempt before that was kvm-88. Hm, okay. As far as I understood it, the auto-add feature should be similar to the USB 1.1, right? It seems to work basically but not fully - the system is somehow slowed down, maybe the polling timer is too fast? (I will play a little bit with that and review and compare as well the auto routine) And the usb-tablet should be an uhci-emulated component, that should then not interfere with the ehci-emulation, right? My proposal from July 2010 was to have emulated devices state their version and have host devices try EHCI then UHCI. This means that the tablet device is attached to UHCI and a host USB key is attached to EHCI. Like this: info usb Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet Device 1.1, Port , Speed 480 Mb/s, Product DT 101 II (qemu) That's what the patch I sent does. EHCI does have a lot higher frame rate and in its current form does have a noticeable impact on CPU usage when devices are connected and one of the lists is activated. If the OS deactivates the controller when there is nothing to do (e.g., not actively talking to the device), cpu usage goes down. Thanks for the explanation! I just tried a few scenarios with the X and V versions of those GUI based guests and an external key attached to EHCI bus worked fine and the usb tablet also worked fine. I did notice some differences in command syntax. For instance, my scripts still use the older -usbdevice tablet syntax and I did not see the USB stall message. Switching to '-device usb-tablet' did generate the message at boot (though overall it seems to be harmless). Nothing fancy with the setup -- ide drive, virtio or e1000 networking, ac97 sound, no-hpet and usb tablet devices. In the time it took to write this response about 900MB was transferred to the usb key at about 1.7-1.8MB/sec rate. David I will give it another try tomorrow. I use -usb -device usb-tablet -device usb-host The last parameter for the auto-add to the guest I will also try the old parameter syntax. What does the no-hpet option do? Might this be somehow significant regarding the performance? Best regards, Erik P.S. When EHCI was active today without tablet and without auto-add I got a transfer rate of ~5MByte/sec from USB key to the HDD. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VNC and SDL/VGA simultaneously?
Hi all, is it possible to parameterize qemu in a way where the VNC port and the VGA output is available in parallel? My system screen remains dark if I run it with the -vnc :0 option and vnc is unavailable when SDL/VGA is available. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
David Ahern wrote: On 03/09/11 08:40, erik.r...@rdsoftware.de wrote: But some things are not working and cause my Windows guest to stop booting or getting slowed down: -device usb-tablet -device usb-mouse do not really work. (I have connected a PS/2 mouse to have no interference with the rest of the USB system that works fine without the patch) If I add them to the command line, windows does not boot up (it hangs before the GUI comes up with ~ 12% CPU time on the host side) If I add them at runtime via the qemu console it has no influence to the guest - I still see no possibility grabbing the mouse to the client Did those work with the previous qemu-kvm releases you tested? I've tried it long time ago with kvm-88, but there it was working but extremely slow. (At least the mouse was reacting there) -device usb-host (for adding all USB devices automatically to the client) works only partly. The client is slowed down when having activated this function but e.g. the USB key gets detected - but not completely, Windows seem to hang somewhere after having got the hardware and before displaying the key in the Explorer (works without the patch) Similarly, how does this compare to prior qemu-kvm releases? I'm not sure if that had worked with kvm-88 automatically - sorry. If one of the above options are enabled I get sometimes a "USB Stall" displayed in the qemu-console. Additonally these lines appear: ehci: PERIODIC list base register set while periodic schedule and ehci: ASYNC list address register set while async schedule According to the EHCI spec an OS is not allowed to do that when the schedule and controller are enabled. It's more informational than anything that OS is not compliant. ok. (Windows is the OS :-)) If I can help you or give you more feedback or even try out new patches, just let me know. I'm really interested in solving the "missing features". Someone needs to dig into the EHCI spec and the code. I lost momentum on it last summer for various reasons. David Hm, okay. As far as I understood it, the auto-add feature should be similar to the USB 1.1, right? It seems to work basically but not fully - the system is somehow slowed down, maybe the polling timer is too fast? (I will play a little bit with that and review and compare as well the auto routine) And the usb-tablet should be an uhci-emulated component, that should then not interfere with the ehci-emulation, right? If you have any additional hints where to start digging, just let me know. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB EHCI patch for 0.14.0?
Hi David, looks really impressive. It works and the performance is really good! But some things are not working and cause my Windows guest to stop booting or getting slowed down: -device usb-tablet -device usb-mouse do not really work. (I have connected a PS/2 mouse to have no interference with the rest of the USB system that works fine without the patch) If I add them to the command line, windows does not boot up (it hangs before the GUI comes up with ~ 12% CPU time on the host side) If I add them at runtime via the qemu console it has no influence to the guest - I still see no possibility grabbing the mouse to the client -device usb-host (for adding all USB devices automatically to the client) works only partly. The client is slowed down when having activated this function but e.g. the USB key gets detected - but not completely, Windows seem to hang somewhere after having got the hardware and before displaying the key in the Explorer (works without the patch) If one of the above options are enabled I get sometimes a "USB Stall" displayed in the qemu-console. Additonally these lines appear: ehci: PERIODIC list base register set while periodic schedule and ehci: ASYNC list address register set while async schedule If I can help you or give you more feedback or even try out new patches, just let me know. I'm really interested in solving the "missing features". Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB EHCI patch for 0.14.0?
Hi all, I've found a usb ehci patch here in the mailing list (begin of january) but it does not fit for 0.14.0. Is there an updated patch for the latest qemu-kvm version? Thanks a lot. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Converting QEMU Harddisk to native Partition
David Mair wrote: I have currently virtualized two partitions (/dev/sda2 and /dev/sda3) that are exposed as QEMU Harddisks to the Windows XP Guest (Drive C and D there). Are there possibilities to convert or adapt those to native partitions or native disks so that I could theoretically boot the Windows that is placed in the virtual disk natively? Anything that works on real hardware is likely to work if run in a guest. At the very least, one of several similar and equivalent methods would be, create another virtual disk a bit bigger than the Windows partition you want to make native and attach it to a VM with the Windows partition you want to make native and boot a linux rescue disk. Put a linux file system on the new disk and mount it (say at /mnt/workspace) then, assuming the Windows partition you want to make native is hda1: # dd if=/dev/sda2 of=/mnt/workspace/windowsCdrive.img bs=1M # dd if=/dev/sda3 of=/mnt/workspace/windowsDdrive.img bs=1M # scp /mnt/workspace/windows*img user@vmhost:~/ I'm assuming you get how that would give you a block copy of the guest partitions as files on the host, which you could then lay down on a real disk via dd and a USB device for example. Yeah, I thought about a similar approach already but it looked too complex to me :-) I assume that my hardware resources might be too limited for such an operation, but I will give it a try. For saving space I could try to do a .gz or .tgz out of it right (using "dd | tar...")? Are there other possibilities from the host side to handle that? I heard about the qemu-img tool but it doesn't seem to match my usecase. Or have I just missed some parameters? Thanks. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Converting QEMU Harddisk to native Partition
Hi all, I have currently virtualized two partitions (/dev/sda2 and /dev/sda3) that are exposed as QEMU Harddisks to the Windows XP Guest (Drive C and D there). Are there possibilities to convert or adapt those to native partitions or native disks so that I could theoretically boot the Windows that is placed in the virtual disk natively? Thanks! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compiling qemu 0.13.0
Hi all, I want to compile qemu 0.13.0 against a 2.6.29.4 kernel. I found no kvm-kmod sources for this kernel. Do I need them? I tried to compile qemu but it fails for the virtio pci because the struct kvm_irq_routing_entry was not found. But this struct is existing in the kvm sources within this qemu version. Is that a bug in the makefiles or am I doing something wrong? I found an email from Avi dated 10.10.2010 where this struct should be avoided to be used if CONFIG_KVM is disabled. So I disabled KVM in my kernel sources - doesn't help, same error. Any ideas how to proceed? Changing the kernel version is quite complex for my project and I want to avoid that. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Scanner
David Ahern wrote: The attached work for me with an Epson CX7800. I was able to print and scan with Vista; driver setup for XP was more of a pain - I only got the printer setup working. It's the EHCI code from git://git.kiszka.org/qemu.git ehci with http://www.mail-archive.com/qemu-devel@nongnu.org/msg38795.html and a couple of local additions. Applies cleanly to qemu-kvm.git as of today (b724fa4bb46b82c54b5f0a2cf9177194020433efO). EHCI is not ready for prime time, but works for use cases like this one. David Hi David, thanks for the patch. Have you tested USB transfer rates using a USB Memory Stick or something similar? If yes, which transfer rates have you reached? Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Scanner
Matthias Henze (L) wrote: Hi, finally I've tried to connect a USB scanner to a KVM VM. I've done so by adding hostusb: 04a9:1606 to the VMs conf. The scanner is detected by Windows XP and at first it seemed to work. It scanns but then "CapturePerfect" hangs for ever. lsusb reports: Bus 002 Device 005: ID 04a9:1606 Canon, Inc. and "info usb": Device 0.1, Speed 12 Mb/s, Product QEMU USB Tablet Device 0.3, Speed 12 Mb/s, Product QEMU USB Hub Device 0.2, Speed 480 Mb/s, Product CANON DR-5010C and "info usbhost": Device 1.1, speed 480 Mb/s Hub: USB device 1d6b:0002, EHCI Host Controller Device 2.1, speed 480 Mb/s Hub: USB device 1d6b:0002, EHCI Host Controller Device 3.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 4.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 5.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 6.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 7.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 8.1, speed 12 Mb/s Hub: USB device 1d6b:0001, UHCI Host Controller Device 1.2, speed 480 Mb/s Hub: USB device 04b4:6560 Device 6.2, speed 12 Mb/s Class 00: USB device :, SE USB Device Device 8.2, speed 1.5 Mb/s Class 00: USB device 046a:0101, Wireless Desktop Device 1.3, speed 480 Mb/s Class 00: USB device 0bc2:2101, FreeAgent Go Device 1.4, speed 480 Mb/s Class 00: USB device 0bc2:2101, FreeAgent Go Device 2.5, speed 480 Mb/s Class 00: USB device 04a9:1606, CANON DR-5010C Auto filters: Device *.* ID 04a9:1606 Can some one pelase help ? This ist a show stopper for this project ... TIA Matthias Hi Matthias, I experienced a similar behaviour with Epson and Canon USB Printers. there the ink fill status readout causes a complete hang of the software (Windows still operational). It seems to be related with USB 2.0 devices. An older USB 1.1 HP Printer works slow but fine. Please check dmesg of the host system, there you should see a lot of USB info messages after plugging in the device. If you get a BSOD in XP when shutting down Windows or when removing the USB Scanner then it is exactly the same issue that I have. It seems (from my point of view) to be related with the KVM-USB virtualization. I could reduce some of the BSOD's by forcing the host USB system to fall back to USB 1.x (switch in BIOS), but printing with the 2.0 devices was still not possible! I have currently no real idea how to solve the issue - additionally the transfer rates of USB are horribly - I do not get more than ~ 64K/sec. If there are improvements on that somewhere "uncomitted" I would like to try them out. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Host Passthrough BSOD on Windows XP
mattia.martine...@gmail.com wrote: Hi. I installed a KVM virtual machine with Windows XP SP3 installed on it with all updates from Windows Update. I setted up an USB device from the host machine to be used on the virtual machine with the command qm set 107 -hostusb 2040:7070 The USB device is an Hauppauge WinTV Nova-T Stick DVB-T USB adapter. Windows recognises the hardware and correctly install its drivers, but when I try to use it (for example tuning some channels) I get the following Blue Screen Of Death: DRIVER_IRQL_NOT_LESS_OR_EQUAL *** STOP: 0x00D1 (0x048C4C04, 0x0002, 0x0001, 0xBA392FD3) *** usbuhci.sys - Address BA392FD3 base at BA39, DateStamp 480254ce Windows' Minudump files tell that the problem is from the usbuhci.sys driver. I'm using Proxmox VE 1.6 (the latest version) with the 2.6.32-2-pve kernel version. Do you have any hint? Thank you very much for your help! Bye. Hi Mattia, I have the same issue since KVM 73. It seems to be related to USB 2.0 hardware. Set your USB Hardware or your host in BIOS to 1.0 or 1.1, boot again. This will result into a max. transfer rate of ~32-64 KB/sec but your Hardware will work more stable. But some USB 2.0 components will still fail if they are not fully USB 1.x capable. I have an old USB HP printer that works slow but fine and a new Canon that crashes Windows with exactly the same driver that hooks up (usbuhci.sys). Sometimes it just doesn't do anything and when unplugging the printer or shutting down the bluescreen comes up. Also have a look on the dmesg of your host! I recognized there a massive connect/disconnect occurence of the given USB device when it is physically connected. The reason seems to be somewhere in the KVM usb layer I tried to find it out but no success. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Detecting Guest Shutdown
Hi all, is it possible to detect a guest shutdown? I want to stop a service if my windows guest is shutted down and force a sync of the disks - because it could be possible that the user switches off the system afterwards and he has no possiblity to tell linux to shut down safely, because he only sees the shutted down screen of windows. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows Driver for -vga std
Hi all, using the Default VGA settings Windows XP detects an unknown VGA Device, but everything is fine, Display settings are ok. But how can I setup my XP to detect this virtual graphics board correctly? I just want to continue using this setting but with no complaints in the system/hardware settings. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCI Device Assignment without VT-d?
Hi all, I've "only" a core2duo with VT, is it somehow possible to use the PCI device assignment without VT-d? That would be great because I cannot upgrade the Mainboard for my system. If yes, what other prerequisites must be fulfilled? Thanks! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Parallel Port question
Hi all, I'm currently running kvm-88 with a parallel port forwarding and Win XP as guest. The Windows XP guest talks directly to the hardware registers of the parallel port and tries to programm a piece of hardware over a proprietary softwar tool. The hardware is connected via Parallel port and a JTAG interface. (The Chip ID is recognized correctly over the port) Running the Windows natively on the system programming is successful. If I run it within the windows guest the Busy flag of the parallel port seems to be "too slow". That means the software expects a low signal but the bit is still set. Are there any posibilities to enable a more direct access to the parallel port? Am I able to map "somehow" the heap of I/O registers directly into the guest for accessing it? What does the "linux host driver layer" do with the parallel port bits? Are they somehow modified within the driver? Thanks! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Jim Paris wrote: Erik Rull wrote: Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim Hm, what I forgot to say: Now the bluescreen comes up directly after trying to print, before it only appeared on unplugging or shutdown. And: It seems to be a USB 2.0 issue. When I plug in a USB 1.1 printer everything is fine?? Can you recommend a usb sniffer tool? Hope this helps when getting a bluescreen :-) Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Jim Paris wrote: Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial Port Driver does not handle interrupt
Rodrigo Campos wrote: On Tue, Nov 17, 2009 at 12:01:08AM +0100, Erik Rull wrote: Erik Rull wrote: Any Ideas? I also tested other IRQ lines and other ttyS* on the system - same behaviour. fixed, apic on host side was disabled, kvm / qemu seems to need it. I think I hit the same issue. What did you do exactly to solve it ? Enable a kernel option ? May I ask which one ? :) Sorry, I dont have the hardware right now (so I can't play with apic options). I will have it in a few weeks, so that's why I am asking :) I enabled the APIC stuff in Kernel and removed my lapic noapic boot parameters. APIC is enabled if you look into /proc/interrupts and the IRQ type is something with apic and not pc / xt. Also ensure that the IRQ line of the serial port matches those of your linux drivers! Otherwise the interrupt gets lost and you'll see some strange behaviours (Chars missing, delayed responses,...). Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Jim Paris wrote: Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Jim, thanks - I will try that tomorrow. - Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial Port Driver does not handle interrupt
Erik Rull wrote: Hi all, I've tested two kvm versions 77 and 88, both with the same behaviour: I add a serial device with -serial /dev/ttyS0 to my guest and launched HyperTerm on my Windows Guest. Additionally I plugged in a loopback plug on the serial connector that just routes back the data send back to the receive line (TXD -> RXD). When I enter characters on the Hyperterm all characters are displayed except the last one that was sent. When I plug in a real serial device and request its status via Hyperterm I get only back the first 16 chars (I expect 50) when I send an additional dummy character (sizeof: 16550 FIFO buffer). On my normal Windows PC it works as expected - so it seems to be an issue with kvm. In the linux host, I don't see any changes in /proc/interrupts, the driver is opened and exclusively on this interrupt line. Within the host the serial line works without any problems, and there, the interrupt counts increase during normal operation with a software that runs on the host and that uses this serial line. What must I do to bring the serial line to real life with a complete communication without any data lost caused by missing interrupts? At the moment this is a key issue that has to be solved to continue my work with kvm. Any Ideas? I also tested other IRQ lines and other ttyS* on the system - same behaviour. Thanks in advance, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html fixed, apic on host side was disabled, kvm / qemu seems to need it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial Port Driver does not handle interrupt
Erik Rull wrote: Hi all, I've tested two kvm versions 77 and 88, both with the same behaviour: I add a serial device with -serial /dev/ttyS0 to my guest and launched HyperTerm on my Windows Guest. Additionally I plugged in a loopback plug on the serial connector that just routes back the data send back to the receive line (TXD -> RXD). When I enter characters on the Hyperterm all characters are displayed except the last one that was sent. When I plug in a real serial device and request its status via Hyperterm I get only back the first 16 chars (I expect 50) when I send an additional dummy character (sizeof: 16550 FIFO buffer). On my normal Windows PC it works as expected - so it seems to be an issue with kvm. In the linux host, I don't see any changes in /proc/interrupts, the driver is opened and exclusively on this interrupt line. Within the host the serial line works without any problems, and there, the interrupt counts increase during normal operation with a software that runs on the host and that uses this serial line. What must I do to bring the serial line to real life with a complete communication without any data lost caused by missing interrupts? At the moment this is a key issue that has to be solved to continue my work with kvm. Any Ideas? I also tested other IRQ lines and other ttyS* on the system - same behaviour. Thanks in advance, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html fixed, apic on host side was disabled, kvm / qemu seems to need it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows XP Bluescreen when unplugging printer
Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Serial Port Driver does not handle interrupt
Hi all, I've tested two kvm versions 77 and 88, both with the same behaviour: I add a serial device with -serial /dev/ttyS0 to my guest and launched HyperTerm on my Windows Guest. Additionally I plugged in a loopback plug on the serial connector that just routes back the data send back to the receive line (TXD -> RXD). When I enter characters on the Hyperterm all characters are displayed except the last one that was sent. When I plug in a real serial device and request its status via Hyperterm I get only back the first 16 chars (I expect 50) when I send an additional dummy character (sizeof: 16550 FIFO buffer). On my normal Windows PC it works as expected - so it seems to be an issue with kvm. In the linux host, I don't see any changes in /proc/interrupts, the driver is opened and exclusively on this interrupt line. Within the host the serial line works without any problems, and there, the interrupt counts increase during normal operation with a software that runs on the host and that uses this serial line. What must I do to bring the serial line to real life with a complete communication without any data lost caused by missing interrupts? At the moment this is a key issue that has to be solved to continue my work with kvm. Any Ideas? I also tested other IRQ lines and other ttyS* on the system - same behaviour. Thanks in advance, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interrupt Assignment on host
Avi Kivity wrote: On 10/28/2009 11:16 PM, Erik Rull wrote: Hi all, after several tests it seems that the interrupt assignment on the host systems influences the kvm performance drastically. If eth0, video and usb are on seperate interrupts the perfomance is way better than if they are shared (that means on the same one). Normally this should not matter. But why is it within kvm? Does kvm somehow hook up into the interrupt service routines? No. My guest is Windows XP SP3. Can you describe how performance suffers? Please provide vmstat (for host int/sec) and "kvm_stat -l -f 'exits|irq_exits'" output. I'm sorry, but my target system has no python installed. Any ideas how to do that manually? - Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU change causes hanging of .NET apps
Avi Kivity wrote: On 11/03/2009 05:11 PM, Timur Safin wrote: My totally noob in QEMU guess - my bet it's CR4.OSFXSR which is controlled by presence of cpuid.1.edx[24] - FXSR bit (FXSAVE and FXRSTOR) instructions. That would affect floating point as well. I'm curious - is there any way in QEMU to redefine returned cpuid leaf values? It will be interesting to see results if that given bit will be disabled in configuration. qemu -cpu host,-flag I tried that value, result is an error: Unable to find x86 CPU definition - Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU change causes hanging of .NET apps
Avi Kivity wrote: On 11/02/2009 01:45 AM, Erik Rull wrote: Hi Avi, Please don't top-post. the Host CPU is a Intel Core2Duo - VT capable and enabled! The problem is that one of the flags that -cpu core2duo enables is implemented incorrectly, so it leads to .net breakage. These flags are pni, lm, nx, ssse3, syscall. Please try -cpu core2duo,-pni,-lm,-nx,-ssse3,-syscall. If it works, remove features one by one until it doesn't and let us know the results. I took all flags, same effect as without all of these flags. :( Any other idea? - Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU change causes hanging of .NET apps
Hi Avi, the Host CPU is a Intel Core2Duo - VT capable and enabled! Best regards, Erik Avi Kivity wrote: On 10/28/2009 11:13 PM, Erik Rull wrote: Hi all, when changing the CPU from the default QEMU32 one to e.g. the n270 or the core2duo no .NET apps will work under Windows XP as guest. Switching back and everything is fine. The Pentium Emulation on the other side works fine! The Application loads but it hangs with 99% CPU usage and ca. 3-4 MB Memory Consumption. Normally, .NET is capable to run on all x86 Processors >= Pentium. XP and non-.NET Apps work fine. Any Ideas what happens here? I also started applications that were NOT started with the QEMU32 CPU to prevent a caching - same problem. What's your host cpu type? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Interrupt Assignment on host
Hi all, after several tests it seems that the interrupt assignment on the host systems influences the kvm performance drastically. If eth0, video and usb are on seperate interrupts the perfomance is way better than if they are shared (that means on the same one). Normally this should not matter. But why is it within kvm? Does kvm somehow hook up into the interrupt service routines? My guest is Windows XP SP3. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CPU change causes hanging of .NET apps
Hi all, when changing the CPU from the default QEMU32 one to e.g. the n270 or the core2duo no .NET apps will work under Windows XP as guest. Switching back and everything is fine. The Pentium Emulation on the other side works fine! The Application loads but it hangs with 99% CPU usage and ca. 3-4 MB Memory Consumption. Normally, .NET is capable to run on all x86 Processors >= Pentium. XP and non-.NET Apps work fine. Any Ideas what happens here? I also started applications that were NOT started with the QEMU32 CPU to prevent a caching - same problem. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Performance
Hi all, has anyone benchmarked the USB performance within a KVM guest. I did with KVM 77 and Windows XP SP3 (host is core2duo with usb1.1 / reduced usb 2.0 because of bluescreens in windows): 64 KByte / sec It seems to be a 64 Byte packet of USB communication each millisecond - thats what I got out, when I entered some debug stuff into the driver. Anyone that got a better performance? If yes, how? Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
Hi there, try to switch to USB 1.1 - not the best way but this helped my Windows XP running and doing things like printing, formatting USB keys or using a Dongle (Aladin, I think, it's also HASP) USB 2.0 was not really working well with KVM :-( Best regards, Erik G wrote: On Thu, Jul 16, 2009 at 9:15 AM, Jim Paris wrote: Hi G, I've continued my attempts to get the HASP dongle working, but with no success: -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-88 release
Hi Avi, Avi Kivity wrote: Note -usbdevice tablet is only eating your cpu. It is not. Unless I don't understand something. With -usbdevice tablet mouse cursor/position is kept syncronized without a need to grab mouse/keyboard. This is very handy and easy. Right, I forgot that bit. I only remembered the better vnc behaviour on some clients. Could you give me a hint how to manage the auto-grab of mouse and keyboard maybe with a patch? A pointer to the code where the grabbing occurs within -usbdevice tablet) would be fine - I would try to add a patch on that and also test it. Maybe it could be a new commandline option (e.g. -autograb)? A better performance with auto-grab and without the -usbdevice parameter would be very nice :-) And this should be the way if I understood the conversion before correctly. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP smp using a lot of CPU
Hi Avi, no I'm using a partition as a drive, here's my command-line: taskset 0x0002 /usr/X11R6/bin/qemu-system-x86_64 -usb -drive file=/dev/hda2,cache=off -m 1536 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -usbdevice tablet -boot c -localtime (I give only one CPU core of the core2duo to the virtualization) $MACADDR was computed before. Best regards, Erik Avi Kivity wrote: Erik Rull wrote: Hi Avi, there are some .NET apps running, doing some calculations and graphic 2D display, HDD access w/ database and some TCP/IP transfer. Are you using qcow2? What is your qemu command line? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP smp using a lot of CPU
Hi Avi, there are some .NET apps running, doing some calculations and graphic 2D display, HDD access w/ database and some TCP/IP transfer. Best regards, Erik Avi Kivity wrote: Erik Rull wrote: Hi Avi, here is the cpuinfo - what do you mean with "workload"? The CPU isage is around 33%. What programs is the guest running? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP smp using a lot of CPU
Hi Avi, here is the cpuinfo - what do you mean with "workload"? The CPU isage is around 33%. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 2 cpu MHz : 1833.554 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no 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 nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3667.98 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 2 cpu MHz : 1833.554 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no 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 nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3666.43 clflush size: 64 Best regards, Erik Avi Kivity wrote: Erik Rull wrote: Hi all, very very interesting. I have a similar problem but the other way round. If my XP runs up tp 100% CPU usage "top" on the linux host reports "only" 33% cpu usage. I would expect around 50% because I only provide one core for the guest. I already increased the process priority of qemu and the io priority, nothing helped. The rest of the CPU is nearly idle, no excessive disk access this time :-) Any Idea what this could be? What workload is the guest running? What is your host cpu type (/proc/cpuinfo)? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP smp using a lot of CPU
Hi all, very very interesting. I have a similar problem but the other way round. If my XP runs up tp 100% CPU usage "top" on the linux host reports "only" 33% cpu usage. I would expect around 50% because I only provide one core for the guest. I already increased the process priority of qemu and the io priority, nothing helped. The rest of the CPU is nearly idle, no excessive disk access this time :-) Any Idea what this could be? Best regards, Erik Ross Boylan wrote: I just installed XP into a new VM, specifying -smp 2 for the machine. According to top, it's using nearly 200% of a cpu even when I'm not doing anything. Is this real CPU useage, or just a reporting problem (just as my disk image is big according to ls, but isn't really)? If it's real, is there anything I can do about it? kvm 0.7.2 on Debian Lenny (but 2.6.29 kernel), amd64. Xeon chips; 32 bit version of XP pro installed, now fully patched (including the Windows Genuine Advantage stuff, though I cancelled it when it wanted to run). Task manager in XP shows virtually no CPU useage. Please cc me on responses. Thanks for any assistance. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Hi Avi, Avi Kivity wrote: Erik Rull wrote: The file system is the guest's business. Instead of '-hda /dev/hda2', try -drive file=/dev/hda2,cache=none great! cache=off worked - none caused an error. The Timing problem is still present but the XP system is now much more interactive during file access (copy / defrag,...) I will try out the 84 kvm with the irq-reinjection. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Hi Avi, Avi Kivity wrote: Erik Rull wrote: The file system is the guest's business. Instead of '-hda /dev/hda2', try -drive file=/dev/hda2,cache=none great! cache=off worked - none caused an error. The Timing problem is still present but the XP system is now much more interactive during file access (copy / defrag,...) I will try out the 84 kvm with the irq-reinjection. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Hi Avi, Avi Kivity wrote: interface: virtio cache: none format: raw, using a partition or logical volume What are you using? uhm, I'm not sure, I call qemu with: qemu-system-x86_64 -usb -hda /dev/hda2 -m 1536 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -usbdevice tablet -boot c The /dev/hda2 is NTFS formatted - does this make sense, because you wrote sth. with raw... Maybe another file system would be faster? Or is it ignored by the guest system? Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Hi Avi, Avi Kivity wrote: Are you using qcow2? In some cases qcow2 will stall the guest cpu. Note that defragmenting the guest drive may cause the qcow2 file to fragment even more, and will certainly increase its size. I recommend only defragmenting when using raw storage. I don't think so. I created a partition on my host "real" harddrive and provided this partition to my windows guest. If you have an idea, which virtualized drive system could be the fastest (except giving a complete disk to the guest), your comments are welcome :-) Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm-77 Excessive Disk Access causes real time clock hang!
Hi all, I'm running kvm-77 and windows xp as guest. When I start the defragmentation of the virtualized drive within the windows guest (well this is not a fine way, but it should work :-)), the real time clock starts hanging - I recognized that because some underlying hardware with own timers began to run out of synchronization. I did some research, took a stopwatch and measured against the system time. During the measurement of ~ 30 seconds I got a difference to the linux time (I just called "watch -n 1 date" which should come from the mainboard system time, doesn't it?) of ~10 seconds! This was the biggest difference I could measure, sometimes it was a little bit less. What's happening here? I reduced the io priority and the guest process priority to a very low one - it didn't help! Oh - I'm running the stuff on an Intel Core2Duo T5600 @ 1.83GHz with 2 Gig of RAM (Windows gets 1.5 Gig), the disk is an SATA with 40 Gigs. Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-linux.c - delay between USB URBs
Hello, hm - interesting, the performance could be really increased. But only a little bit - its now around 60kb/sec (okay a factor of nearly 2) - the average delay is still around 1 msec. Well faster but not at a real USB limit. I played around with the count value and 10 seems to be one of the best. Any other Ideas? The Windows XP shows me a pretty old USB Host adaptor, is there a way to change to a newer one? The chipset is now nearly 11 years old :-) Best regards, Erik Xin, Xiaohui wrote: > Erik, > Did you use uhci or ehci controller in qemu? If uhuci, then > Don’t know we are met the same issue or not. May you try the patch to see if > it has some effect or not? We observe it has effect on native qemu side. > > The patch is simple but experimental, you may try to modify the "count" > number as you need to see a effect. > > Thanks > Xiaohui > > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf > Of Erik Rull > Sent: 2009年3月19日 5:42 > To: kvm@vger.kernel.org > Subject: usb-linux.c - delay between USB URBs > > Hello, > > my problem is still the same - the USB key has only a transfer rate of ~ 2 > MB / min through the virtualization. > > So I did some debugging in usb-linux.c - first I switched on debugging. > The debug output was way to much so I added a timestamp calculation between > a) start and end of async transfer and b) end of one and start of the next > block (each block is 64 bytes large). > The transfer rate of the driver itself is ~ 200kByte / sec - quite fine and > much faster than the complete chain (only ~32kByte / sec). > The delay between one and the next packet is ~2msec (transfer of 2MByte > from USB key to HDD measured)! that means, 64 bytes are transferred then a > pause of nearly 2msec is placed and then the next 64 bytes are sent to the > driver. This fits nearly exactly my measured transfer rate of 32kByte /sec > (64 Bytes / 2msec => 32kByte / sec). > > Where do the 2 msec come from? I have no real other processes running that > could interfere here. In the Windows guest there is nothing else but the > windows explorer and some other standard processes running. > Any Idea where to continue searching for these 2msecs?? > > Best regards, > > Erik > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb-linux.c - delay between USB URBs
Hello, my problem is still the same - the USB key has only a transfer rate of ~ 2 MB / min through the virtualization. So I did some debugging in usb-linux.c - first I switched on debugging. The debug output was way to much so I added a timestamp calculation between a) start and end of async transfer and b) end of one and start of the next block (each block is 64 bytes large). The transfer rate of the driver itself is ~ 200kByte / sec - quite fine and much faster than the complete chain (only ~32kByte / sec). The delay between one and the next packet is ~2msec (transfer of 2MByte from USB key to HDD measured)! that means, 64 bytes are transferred then a pause of nearly 2msec is placed and then the next 64 bytes are sent to the driver. This fits nearly exactly my measured transfer rate of 32kByte /sec (64 Bytes / 2msec => 32kByte / sec). Where do the 2 msec come from? I have no real other processes running that could interfere here. In the Windows guest there is nothing else but the windows explorer and some other standard processes running. Any Idea where to continue searching for these 2msecs?? Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Transfer Rate with kvm-77
Hello, I'm currently testing Windows XP in a Linux host. I works well except the USB transfer rate. Printers and USB Pen Drives can be connected and get detected (I added host:auto...). My System only supports USB 1.1, the transfer rate in plain linux is okay. In the Guest Windows, the transfer rate is horribly slow! The transfer rate is ~ 2MB per Minute! This is far below the slowest defined USB transfer rates (1,5MBit / sec!). The system is nearly idle (in linux and windows) during the transfer. What could be the reason for that? I tested it also on a USB 2.0 system, same effect, but additionally the printers cause bluescreens within Windows :-) I need some ideas where to start investigating. I tested several USB Pen Drives (USB 2.0 capable), a USB DVD ROM Drive and two printers of different manufacturers (HP, Canon). All at the same transfer rate :-( It seems that there is a performance gap - but where? Thanks a lot! Best regards, Erik -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
