Re: KVM, Entropy and Windows
On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: Hello all, I believe I am hitting a problem on one of our Windows 2003 KVM guests were I believe it is running out of Entropy and causing SSL issues. I see that there is a module called virtio-rng which I believe passes the HW entropy source through to the guest but does this work on Windows as-well ? AFAIK there is no Windows driver for virtio-rng. Seems like a good idea. Vadim? If it doesn't any ideas on how I can increase the amount of entropy being generated on a headless system ? or even monitor entropy on a Windows system ? No idea. Maybe you could ask Windows to collect entropy from packet timings. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/16/2011 03:34 PM, Anthony Liguori wrote:
On 02/16/2011 04:24 AM, Avi Kivity wrote:
On 02/16/2011 01:13 AM, Anthony Liguori wrote:
On 02/15/2011 10:26 AM, Chris Wright wrote:
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
http://wiki.qemu.org/Features/QAPI
[ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'},
'none' ]
-
void qmp_change(const char *device, const char *target, bool
has_arg, const char *arg, Error **errp);
AFAICT a json-string allows embedded NULs ('\'). There translate
to UTF-8 as '\0', terminating your char *s. Either we use some
length/pointer structure, or the parser has to look for them and kill
them, and we have to specify them as verboten.
I feel like it would be safer for us to not accept strings with
embedded NULs. There's no way we're going to consistently handle this
correctly in QEMU since we expect NUL terminated strings. They won't
work for any of the standard C functions either.
I agree. Technically we're making a backwards incompatible change to
the protocol specification, but I don't think there's any risk that
somebody is sending in strings with NULs.
(btw what happens in a non-UTF-8 locale? I guess we should just reject
unencodable strings).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: VMX: Short circuit STI; HLT while an interrupt is pending
On 02/16/2011 06:51 PM, Marcelo Tosatti wrote:
On Wed, Feb 16, 2011 at 11:01:47AM +0200, Avi Kivity wrote:
On 02/15/2011 10:36 PM, Marcelo Tosatti wrote:
On Mon, Feb 14, 2011 at 04:42:16PM +0200, Avi Kivity wrote:
Short-circuit an STI; HLT sequence while an interrupt is pending:
instead of halting, re-entering the guest, and exiting immediately
on an interrupt window exit, go directly to the last step.
Saves a vmexit on workloads where interrupts are received synchronously;
an example is a disk backed by the host page cache where there is no
latency (from the guest's point of view) between the request and
fulfilment.
Signed-off-by: Avi Kivitya...@redhat.com
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ee1cd1a..541da0e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3437,6 +3437,15 @@ static int handle_interrupt_window(struct
kvm_vcpu *vcpu)
static int handle_halt(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction(vcpu);
+ /*
+ * Short-circuit an STI; HLT sequence while an interrupt is
pending:
+ * instead of halting, re-entering the guest, and exiting
immediately
+ * on an interrupt window exit, go directly to the last step.
+ */
+ if ((to_vmx(vcpu)-cpu_based_vm_exec_control
+ CPU_BASED_VIRTUAL_INTR_PENDING)
+ (kvm_get_rflags(vcpu) X86_EFLAGS_IF))
+ return handle_interrupt_window(vcpu);
return kvm_emulate_halt(vcpu);
}
Why does the normal vcpu entry path fails to inject the interrupt? Because
after halt,
KVM_REQ_EVENT is not set?
Yes. Also, we want to clear CPU_BASED_VIRTUAL_INTR_PENDING.
Is there a reason why it cannot be handled in the main loop?
Don't follow. What are you suggesting?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why exit on MSR_STAR and friends?
On 02/16/2011 05:17 PM, Nadav Har'El wrote: Hi, In the recent KVM forum, Marcelo Tosatti presented some KVM performance improvements. One of them (page 17 of the presentation) was about the MSRs used by SYSCALL: MSR_STAR, MSR_LSTAR, MSR_CSTAR (and also MSR_SYSCALL_MASK). He said that Guests have direct access to these MSRs, and this is why KVM needs to restore their original host value when returning to user space (they aren't used in the kernel, so there's no reason to restore them earlier). I was suprised, then, to discover that KVM doesn't add these MSRs to the MSR bitmap, so when the guest changes these MSR values, or even reads them, we cause an exit - both on read and on write of these MSRs. I was wondering why these exits are needed. I can maybe guess why an exit is needed on write - just to save the guest value so we don't need to read it when going back to user space. Is this a good optimization because we assume that the guest very rarely changes these MSRs? Exactly. Or is there another explanation as to why these exits are needed? No. But I can't even guess why an exit is needed on read... It isn't needed. The code doesn't distinguish between the read and write bitmaps, and so far no guest issues rdmsr for these msrs with any frequency (kvm as a guest will write those msrs, but it shouldn't read them on Intel). Do you see frequent reads on some guest? If you're curious why I noticed these exits - I was running a nested KVM (L0's guest L1 is KVM, that itself has a guest L2). Whenever L2 does something that L1 needs to handle in user space (e.g., PIO), L1 does all these MSR reads and writes, and we get exits for each of them - many of those exits for each L2 PIO :( It shouldn't be doing MSR reads. The only MSR read I can see is for SYSENTER_ESP when a vcpu is migrated (easily avoided). But maybe I'm missing something. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM, Entropy and Windows
On Thu, 2011-02-17 at 11:11 +0200, Avi Kivity wrote: On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: Hello all, I believe I am hitting a problem on one of our Windows 2003 KVM guests were I believe it is running out of Entropy and causing SSL issues. I see that there is a module called virtio-rng which I believe passes the HW entropy source through to the guest but does this work on Windows as-well ? AFAIK there is no Windows driver for virtio-rng. Seems like a good idea. Vadim? virtio-rng driver for windows is not a big deal. IMO, the real problem will be to force Windows to use for CriptoApi. If it doesn't any ideas on how I can increase the amount of entropy being generated on a headless system ? or even monitor entropy on a Windows system ? No idea. Maybe you could ask Windows to collect entropy from packet timings. -- 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: Why exit on MSR_STAR and friends?
On Thu, Feb 17, 2011, Avi Kivity wrote about Re: Why exit on MSR_STAR and friends?: It isn't needed. The code doesn't distinguish between the read and write bitmaps, and so far no guest issues rdmsr for these msrs with any frequency (kvm as a guest will write those msrs, but it shouldn't read them on Intel). Do you see frequent reads on some guest? I saw reads of all these MSRs (STAR, LSTAR, CSTAR and SYSCALL_MASK) at about half the number of the writes. Looking deeper now, I realize why I saw these and you didn't. I happened to run some old L1 image, with apparently a 1 year old Linux and KVM. In that version, __vmx_load_host_state() called: save_msrs(vmx-guest_msrs, vmx-save_nmsrs); load_msrs(vmx-host_msrs, vmx-save_nmsrs); and save_msrs read all those MSRs. Looking at the current code, indeed this is no loger done. So you can say that there are some guests which frequently reads those MSRs - old versions of KVM :-) But I agree, this is nothing to worry about. I guess I should be more worried why I got all these PIOs in L2 in the first place - the MSR reads and writes in L1 were just an odd consequence of that. It turns out that the ping -f workload I was running in L2 insisted to get accurate timings of each packet, and this, I'm not still sure why, caused a ACPI PM_TIMER PIO for each packet. I guess that normal workloads won't use the timer on every packet, so that shouldn't matter. -- Nadav Har'El|Thursday, Feb 17 2011, 13 Adar I 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Knowledge is knowing a tomato is a fruit. http://nadav.harel.org.il |Wisdom is not putting it in a fruit salad. -- 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, Entropy and Windows
On 02/17/2011 12:09 PM, Vadim Rozenfeld wrote: On Thu, 2011-02-17 at 11:11 +0200, Avi Kivity wrote: On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: Hello all, I believe I am hitting a problem on one of our Windows 2003 KVM guests were I believe it is running out of Entropy and causing SSL issues. I see that there is a module called virtio-rng which I believe passes the HW entropy source through to the guest but does this work on Windows as-well ? AFAIK there is no Windows driver for virtio-rng. Seems like a good idea. Vadim? virtio-rng driver for windows is not a big deal. IMO, the real problem will be to force Windows to use for CriptoApi. What's the implication of it? good or bad? Do you know what hyper-v is doing for it? If it doesn't any ideas on how I can increase the amount of entropy being generated on a headless system ? or even monitor entropy on a Windows system ? No idea. Maybe you could ask Windows to collect entropy from packet timings. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why exit on MSR_STAR and friends?
On 02/17/2011 12:29 PM, Nadav Har'El wrote: I guess I should be more worried why I got all these PIOs in L2 in the first place - the MSR reads and writes in L1 were just an odd consequence of that. It turns out that the ping -f workload I was running in L2 insisted to get accurate timings of each packet, and this, I'm not still sure why, caused a ACPI PM_TIMER PIO for each packet. I guess that normal workloads won't use the timer on every packet, so that shouldn't matter. Strange, isn't kvmclock exposed to L2? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt00.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov%rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub$0x20,%rsp 0xf8000c485a8a: mov%rcx,%rdi 0xf8000c485a8d: xor%ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc%ebx 0xf8000c485a92: test %ebx,0x274834(%rip)# 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov(%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov%ebx,%eax 0xf8000c485ab2: mov0x30(%rsp),%rbx 0xf8000c485ab7: add$0x20,%rsp 0xf8000c485abb: pop%rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Any help or comment is appreciated. BYtE Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ ** Besuchen Sie uns auf der CeBIT in Hannover ** ** Auf dem Univention Stand D36 in Halle 2** ** Vom 01. bis 05. März 2011 ** signature.asc Description: This is a digitally signed message part.
Re: KVM, Entropy and Windows
On Thu, 2011-02-17 at 12:37 +0200, Dor Laor wrote: On 02/17/2011 12:09 PM, Vadim Rozenfeld wrote: On Thu, 2011-02-17 at 11:11 +0200, Avi Kivity wrote: On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: Hello all, I believe I am hitting a problem on one of our Windows 2003 KVM guests were I believe it is running out of Entropy and causing SSL issues. I see that there is a module called virtio-rng which I believe passes the HW entropy source through to the guest but does this work on Windows as-well ? AFAIK there is no Windows driver for virtio-rng. Seems like a good idea. Vadim? virtio-rng driver for windows is not a big deal. IMO, the real problem will be to force Windows to use for CriptoApi. What's the implication of it? good or bad? iirc, Vista and higher use a new generation of cryptography API. CriptoApi can be integrated with smart cards sub-system. If we can make Windows virtio-rng driver to be attachable to smart cart devstack, I think we can solve the problem. Do you know what hyper-v is doing for it? No idea. If it doesn't any ideas on how I can increase the amount of entropy being generated on a headless system ? or even monitor entropy on a Windows system ? No idea. Maybe you could ask Windows to collect entropy from packet timings. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn h...@univention.de wrote: Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt0 0.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov %rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub $0x20,%rsp 0xf8000c485a8a: mov %rcx,%rdi 0xf8000c485a8d: xor %ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc %ebx 0xf8000c485a92: test %ebx,0x274834(%rip) # 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov (%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne 0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov %ebx,%eax 0xf8000c485ab2: mov 0x30(%rsp),%rbx 0xf8000c485ab7: add $0x20,%rsp 0xf8000c485abb: pop %rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? One option may might be to set up the Windows debugger in order to closely monitor what the guest is doing when it hangs or BSODs: http://etherboot.org/wiki/sanboot/winnt_iscsi_debug Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn h...@univention.de wrote: Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt0 0.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov %rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub $0x20,%rsp 0xf8000c485a8a: mov %rcx,%rdi 0xf8000c485a8d: xor %ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc %ebx 0xf8000c485a92: test %ebx,0x274834(%rip) # 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov (%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne 0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov %ebx,%eax 0xf8000c485ab2: mov 0x30(%rsp),%rbx 0xf8000c485ab7: add $0x20,%rsp 0xf8000c485abb: pop %rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? One option may might be to set up the Windows debugger in order to closely monitor what the guest is doing when it hangs or BSODs: http://etherboot.org/wiki/sanboot/winnt_iscsi_debug Why is is linked to virtio? Does install on ide work? Does install work without -no-kvm-irqchip (which had pretty serious problem till now)? Adding -no-kvm-irqchip usually does not solve problems, but just exchange one set of bugs to the other (and reduces performance drastically). -- Gleb. -- 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] KVM call minutes for Feb 15
On 02/17/2011 03:26 AM, Avi Kivity wrote:
On 02/16/2011 03:34 PM, Anthony Liguori wrote:
On 02/16/2011 04:24 AM, Avi Kivity wrote:
On 02/16/2011 01:13 AM, Anthony Liguori wrote:
On 02/15/2011 10:26 AM, Chris Wright wrote:
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
http://wiki.qemu.org/Features/QAPI
[ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'},
'none' ]
-
void qmp_change(const char *device, const char *target, bool
has_arg, const char *arg, Error **errp);
AFAICT a json-string allows embedded NULs ('\'). There
translate to UTF-8 as '\0', terminating your char *s. Either we use
some length/pointer structure, or the parser has to look for them
and kill them, and we have to specify them as verboten.
I feel like it would be safer for us to not accept strings with
embedded NULs. There's no way we're going to consistently handle
this correctly in QEMU since we expect NUL terminated strings. They
won't work for any of the standard C functions either.
I agree. Technically we're making a backwards incompatible change to
the protocol specification, but I don't think there's any risk that
somebody is sending in strings with NULs.
(btw what happens in a non-UTF-8 locale? I guess we should just reject
unencodable strings).
While QEMU is mostly ASCII internally, for the purposes of the JSON
parser, we always encode and decode UTF-8. We reject invalid UTF-8
sequences. But since JSON is string-encoded unicode, we can always
decode a JSON string to valid UTF-8 as long as the string is well formed.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Enable drilldown for kvm_exit reasons
kvm_stat currently tracks both tracepoints, and also kvm_exit by exit reason. This is somewhat cluttered and also very expensive with the current kernel filter implementation. Make drilldown optional by adding a key to trigger it. Avi Kivity (4): kvm_stat: move groups and events into well defined objects kvm_stat: add wrappers for perf_event enable and disable ioctls kvm_stat: allow enabling/disabling events dynamicalls kvm_stat: add 'x' key for enabling/disabling drilldown kvm/kvm_stat | 149 -- 1 files changed, 103 insertions(+), 46 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] kvm_stat: add wrappers for perf_event enable and disable ioctls
Signed-off-by: Avi Kivity a...@redhat.com --- kvm/kvm_stat |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/kvm/kvm_stat b/kvm/kvm_stat index 371e547..2e1fe73 100755 --- a/kvm/kvm_stat +++ b/kvm/kvm_stat @@ -245,6 +245,12 @@ class Event(object): import fcntl fcntl.ioctl(fd, 0x40082406, filter) self.fd = fd +def enable(self): +import fcntl +fcntl.ioctl(self.fd, 0x2400, 0) +def disable(self): +import fcntl +fcntl.ioctl(self.fd, 0x2401, 0) class TracepointProvider(object): def __init__(self): -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] kvm_stat: move groups and events into well defined objects
Signed-off-by: Avi Kivity a...@redhat.com
---
kvm/kvm_stat | 107 +++--
1 files changed, 66 insertions(+), 41 deletions(-)
diff --git a/kvm/kvm_stat b/kvm/kvm_stat
index f8a1399..371e547 100755
--- a/kvm/kvm_stat
+++ b/kvm/kvm_stat
@@ -201,12 +201,57 @@ PERF_FORMAT_GROUP = 1 3
import re
+sys_tracing = '/sys/kernel/debug/tracing'
+
+class Group(object):
+def __init__(self, cpu):
+self.events = []
+self.group_leader = None
+self.cpu = cpu
+def add_event(self, name, event_set, tracepoint, filter = None):
+self.events.append(Event(group = self,
+ name = name, event_set = event_set,
+ tracepoint = tracepoint, filter = filter))
+if len(self.events) == 1:
+self.file = os.fdopen(self.events[0].fd)
+def read(self):
+bytes = 8 * (1 + len(self.events))
+fmt = '' + 'q' * len(self.events)
+return dict(zip([event.name for event in self.events],
+struct.unpack(fmt, self.file.read(bytes
+
+class Event(object):
+def __init__(self, group, name, event_set, tracepoint, filter = None):
+self.name = name
+attr = perf_event_attr()
+attr.type = PERF_TYPE_TRACEPOINT
+attr.size = ctypes.sizeof(attr)
+id_path = os.path.join(sys_tracing, 'events', event_set,
+ tracepoint, 'id')
+id = int(file(id_path).read())
+attr.config = id
+attr.sample_type = (PERF_SAMPLE_RAW
+| PERF_SAMPLE_TIME
+| PERF_SAMPLE_CPU)
+attr.sample_period = 1
+attr.read_format = PERF_FORMAT_GROUP
+group_leader = -1
+if group.events:
+group_leader = group.events[0].fd
+fd = _perf_event_open(attr, -1, group.cpu, group_leader, 0)
+if fd == -1:
+raise Exception('perf_event_open failed')
+if filter:
+import fcntl
+fcntl.ioctl(fd, 0x40082406, filter)
+self.fd = fd
+
class TracepointProvider(object):
def __init__(self):
-self.base = '/sys/kernel/debug/tracing/events/kvm/'
+path = os.path.join(sys_tracing, 'events', 'kvm')
fields = [f
- for f in os.listdir(self.base)
- if os.path.isdir(self.base + '/' + f)]
+ for f in os.listdir(path)
+ if os.path.isdir(os.path.join(path, f))]
extra = []
for f in fields:
if f in filters:
@@ -226,48 +271,28 @@ class TracepointProvider(object):
import resource
nfiles = len(self.cpus) * 1000
resource.setrlimit(resource.RLIMIT_NOFILE, (nfiles, nfiles))
-fds = []
+events = []
self.group_leaders = []
for cpu in self.cpus:
-group_leader = -1
-for f in _fields:
-fbase, sub = f, None
-m = re.match(r'(.*)\((.*)\)', f)
+group = Group(cpu)
+for name in _fields:
+tracepoint = name
+filter = None
+m = re.match(r'(.*)\((.*)\)', name)
if m:
-fbase, sub = m.groups()
-attr = perf_event_attr()
-attr.type = PERF_TYPE_TRACEPOINT
-attr.size = ctypes.sizeof(attr)
-id = int(file(self.base + fbase + '/id').read())
-attr.config = id
-attr.sample_type = (PERF_SAMPLE_RAW
-| PERF_SAMPLE_TIME
-| PERF_SAMPLE_CPU)
-attr.sample_period = 1
-attr.read_format = PERF_FORMAT_GROUP
-fd = _perf_event_open(attr, -1, cpu, group_leader, 0)
-if fd == -1:
-raise Exception('perf_event_open failed')
-if sub:
-import fcntl
-filter = '%s==%d\0' % (filters[fbase][0],
- filters[fbase][1][sub])
-fcntl.ioctl(fd, 0x40082406, filter)
-if group_leader == -1:
-group_leader = fd
-fds.append(fd)
-self.group_leaders.append(group_leader)
-self.fds = fds
-self.files = [os.fdopen(group_leader)
- for group_leader in self.group_leaders]
+tracepoint, sub = m.groups()
+filter = '%s==%d\0' % (filters[tracepoint][0],
+ filters[tracepoint][1][sub])
+event = group.add_event(name, event_set = 'kvm',
+tracepoint = tracepoint,
+filter = filter)
+self.group_leaders.append(group)
def
[PATCH 3/4] kvm_stat: allow enabling/disabling events dynamicalls
Signed-off-by: Avi Kivity a...@redhat.com
---
kvm/kvm_stat | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/kvm/kvm_stat b/kvm/kvm_stat
index 2e1fe73..e3e9def 100755
--- a/kvm/kvm_stat
+++ b/kvm/kvm_stat
@@ -265,10 +265,11 @@ class TracepointProvider(object):
for name, number in values.iteritems():
extra.append(f + '(' + name + ')')
fields += extra
+self._setup(fields)
self.select(fields)
def fields(self):
return self._fields
-def select(self, _fields):
+def _setup(self, _fields):
self._fields = _fields
cpure = r'cpu([0-9]+)'
self.cpus = [int(re.match(cpure, x).group(1))
@@ -293,6 +294,13 @@ class TracepointProvider(object):
tracepoint = tracepoint,
filter = filter)
self.group_leaders.append(group)
+def select(self, fields):
+for group in self.group_leaders:
+for event in group.events:
+if event.name in fields:
+event.enable()
+else:
+event.disable()
def read(self):
from collections import defaultdict
ret = defaultdict(int)
--
1.7.1
--
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] KVM call minutes for Feb 15
On (Wed) 16 Feb 2011 [08:41:27], Anthony Liguori wrote: On 02/16/2011 08:39 AM, Amit Shah wrote: On (Tue) 15 Feb 2011 [17:13:13], Anthony Liguori wrote: On 02/15/2011 10:26 AM, Chris Wright wrote: revisit new - old migration - Amit offers virtio-serial patches and some legwork So, to me, migration correctness trumps compatibility. I don't think compatibility is useful if it means that a guest may fail during migration. We have subsections as a way to support the cases where it's safe to migrate to an old version only if a feature is not being used or a corner case is not currently happening. This is the best way to approach the problem. If a subsection won't work, that means you want to migrate when you're completely sure that migrating will break a guest. That doesn't seem reasonable at all to me. I think in the last discussion on Amit's patches, I had suggested that subsections could be used to allow migration when there wasn't any queued data. I think this is the best we can do while preserving correctness. The only problem is that virtio hasn't been converted over to vmstate, which is necessary for subsections. Then it needs to be converted. But that can't be done for 0.14. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] kvm_stat: add 'x' key for enabling/disabling drilldown
Pressing 'x' enables drilldown into kvm_exit reasons. Pressing it again reverts to normal behaviour. Signed-off-by: Avi Kivity a...@redhat.com --- kvm/kvm_stat | 26 ++ 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/kvm/kvm_stat b/kvm/kvm_stat index e3e9def..db2d135 100755 --- a/kvm/kvm_stat +++ b/kvm/kvm_stat @@ -311,20 +311,26 @@ class TracepointProvider(object): class Stats: def __init__(self, provider, fields = None): +self.provider = provider +self.fields_filter = fields +self._update() +def _update(self): def wanted(key): import re -if not fields: +if not self.fields_filter: return True -return re.match(fields, key) != None -self.provider = provider +return re.match(self.fields_filter, key) is not None self.values = dict([(key, None) for key in provider.fields() if wanted(key)]) self.provider.select(self.values.keys()) +def set_fields_filter(self, fields_filter): +self.fields_filter = fields_filter +self._update() def get(self): new = self.provider.read() for key in self.provider.fields(): -oldval = self.values[key] +oldval = self.values.get(key, (0, 0)) newval = new[key] newdelta = None if oldval is not None: @@ -346,6 +352,15 @@ number_width = 10 def tui(screen, stats): curses.use_default_colors() curses.noecho() +drilldown = False +fields_filter = stats.fields_filter +def update_drilldown(): +if not fields_filter: +if drilldown: +stats.set_fields_filter(None) +else: +stats.set_fields_filter(r'^[^\(]*$') +update_drilldown() def refresh(sleeptime): screen.erase() screen.addstr(0, 0, 'kvm statistics') @@ -379,6 +394,9 @@ def tui(screen, stats): sleeptime = 3 try: c = screen.getkey() +if c == 'x': +drilldown = not drilldown +update_drilldown() if c == 'q': break except KeyboardInterrupt: -- 1.7.1 -- 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: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn h...@univention.de wrote: Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt00.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov%rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub$0x20,%rsp 0xf8000c485a8a: mov%rcx,%rdi 0xf8000c485a8d: xor%ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc%ebx 0xf8000c485a92: test %ebx,0x274834(%rip)# 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov(%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov%ebx,%eax 0xf8000c485ab2: mov0x30(%rsp),%rbx 0xf8000c485ab7: add$0x20,%rsp 0xf8000c485abb: pop%rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? Debugging installation-phase problems on 64-bit platforms is a very complicated thing. If the problem is reproducible on x86 platforms, you can try printing messages (RhelDbgPrint function) to localize the problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build checked (debug) version of the driver. One option may might be to set up the Windows debugger in order to closely monitor what the guest is doing when it hangs or BSODs: http://etherboot.org/wiki/sanboot/winnt_iscsi_debug Why is is linked to virtio? Does install on ide work? Does install work
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/17/2011 06:23 AM, Avi Kivity wrote: On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. QEMU does not support anything but UTF-8. That's pretty common with Unix software. I don't think any modern Unix platform actually uses UCS2 or UTF-16. It's either ascii or UTF-8. The only place it even matters is Windows and Windows has ASCII and UTF-16 versions of their APIs. So on Windows, non-ASCII characters won't be handled correctly (yet another one of the many issues with Windows support in QEMU). UTF-8 is self-recovering though so it degrades gracefully. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/17/2011 03:10 PM, Anthony Liguori wrote: On 02/17/2011 06:23 AM, Avi Kivity wrote: On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. QEMU does not support anything but UTF-8. Since when? AFAICT, JSON string conversion is the only place where there is any dependency on UTF-8. Anything else should just work. That's pretty common with Unix software. I don't think any modern Unix platform actually uses UCS2 or UTF-16. It's either ascii or UTF-8. Most/all Linux distributions support UTF-8 as well as a zillion other encodings (single-byte ASCII + another charset, or multi-byte charsets for languages with many characters. The only place it even matters is Windows and Windows has ASCII and UTF-16 versions of their APIs. So on Windows, non-ASCII characters won't be handled correctly (yet another one of the many issues with Windows support in QEMU). UTF-8 is self-recovering though so it degrades gracefully. It matters on Linux with el_GR.iso88597, for example. If you feed a JSON string and translate it blindly to UTF-8, you'll get garbage when you feed it to system calls. Practically everyone uses UTF-8 these days, so the impact is minimal, but it is more correct (as well as simpler) to ask the system libraries to encode using the current locale. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/17/2011 07:25 AM, Avi Kivity wrote: On 02/17/2011 03:10 PM, Anthony Liguori wrote: On 02/17/2011 06:23 AM, Avi Kivity wrote: On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. QEMU does not support anything but UTF-8. Since when? AFAICT, JSON string conversion is the only place where there is any dependency on UTF-8. Anything else should just work. That's pretty common with Unix software. I don't think any modern Unix platform actually uses UCS2 or UTF-16. It's either ascii or UTF-8. Most/all Linux distributions support UTF-8 as well as a zillion other encodings (single-byte ASCII + another charset, or multi-byte charsets for languages with many characters. Maybe there's some confusion here. UTF-8 is an encoding, not a locale. The common encodings are ASCII, UTF-8, UCS2, UTF-16, and UTF-32. An application has to explicitly support an encoding. It is not transparent. UCS2/UTF-16 means that strings are not 'const char *'s but 'const wchar_t *' where typedef unsigned short wchar_t;. QEMU assumes, in lots of places that strings are single-byte NUL terminated. Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much tie you to ASCII/UTF-8. You can have a single NUL byte as part of a valid UCS2 string. The only place it even matters is Windows and Windows has ASCII and UTF-16 versions of their APIs. So on Windows, non-ASCII characters won't be handled correctly (yet another one of the many issues with Windows support in QEMU). UTF-8 is self-recovering though so it degrades gracefully. It matters on Linux with el_GR.iso88597, for example. The whole series of iso8859 (8-bit encodings) are officially abandoned in favor of UCS and encodings that support the full UCS code page (UTF-8/UTF-16). I see no strong reason to try and support deprecated encodings when there are perfectly valid replacements like el_GR.utf8. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/17/2011 07:25 AM, Avi Kivity wrote: On 02/17/2011 03:10 PM, Anthony Liguori wrote: On 02/17/2011 06:23 AM, Avi Kivity wrote: On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. QEMU does not support anything but UTF-8. Since when? AFAICT, JSON string conversion is the only place where there is any dependency on UTF-8. Anything else should just work. That's pretty common with Unix software. I don't think any modern Unix platform actually uses UCS2 or UTF-16. It's either ascii or UTF-8. Most/all Linux distributions support UTF-8 as well as a zillion other encodings (single-byte ASCII + another charset, or multi-byte charsets for languages with many characters. An application has to explicitly support an encoding. It is not transparent. UCS2/UTF-16 means that strings are not 'const char *'s but 'const wchar_t *' where typedef unsigned short wchar_t;. QEMU assumes, in lots of places that strings are single-byte NUL terminated. Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much tie you to ASCII/UTF-8. You can have a single NUL byte as part of a valid UCS2 string. The only place it even matters is Windows and Windows has ASCII and UTF-16 versions of their APIs. So on Windows, non-ASCII characters won't be handled correctly (yet another one of the many issues with Windows support in QEMU). UTF-8 is self-recovering though so it degrades gracefully. It matters on Linux with el_GR.iso88597, for example. The whole series of iso8859 (8-bit encodings) are officially abandoned in favor of UCS and encodings that support the full UCS code page (UTF-8/UTF-16). I see no strong reason to try and support deprecated encodings when there are perfectly valid replacements like el_GR.utf8. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 17 February 2011 13:37, Anthony Liguori anth...@codemonkey.ws wrote: An application has to explicitly support an encoding. It is not transparent. UCS2/UTF-16 means that strings are not 'const char *'s but 'const wchar_t *' where typedef unsigned short wchar_t;. QEMU assumes, in lots of places that strings are single-byte NUL terminated. Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much tie you to ASCII/UTF-8. Er, no, it limits you to those encodings where you can treat strings as bag of NUL-terminated bytes. Oddly enough just about all the common legacy ones (iso-8859-*, iso-2022-jp, etc) fit in that category because otherwise they'd break really badly. As it is, generally things Just Work for programs which treat filenames as an opaque string. -- PMM -- 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] KVM call minutes for Feb 15
On 02/17/2011 07:59 AM, Peter Maydell wrote: On 17 February 2011 13:37, Anthony Liguorianth...@codemonkey.ws wrote: An application has to explicitly support an encoding. It is not transparent. UCS2/UTF-16 means that strings are not 'const char *'s but 'const wchar_t *' where typedef unsigned short wchar_t;. QEMU assumes, in lots of places that strings are single-byte NUL terminated. Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much tie you to ASCII/UTF-8. Er, no, it limits you to those encodings where you can treat strings as bag of NUL-terminated bytes. Oddly enough just about all the common legacy ones (iso-8859-*, iso-2022-jp, etc) fit in that category because otherwise they'd break really badly. I wasn't even considering those because I think the entire world has moved to unicode/utf* Those functions limit you to UTF-8 which was my original point. Regards, Anthony Liguori As it is, generally things Just Work for programs which treat filenames as an opaque string. -- PMM -- 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] KVM call minutes for Feb 15
On 02/17/2011 03:37 PM, Anthony Liguori wrote: On 02/17/2011 07:25 AM, Avi Kivity wrote: On 02/17/2011 03:10 PM, Anthony Liguori wrote: On 02/17/2011 06:23 AM, Avi Kivity wrote: On 02/17/2011 02:12 PM, Anthony Liguori wrote: (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). While QEMU is mostly ASCII internally, for the purposes of the JSON parser, we always encode and decode UTF-8. We reject invalid UTF-8 sequences. But since JSON is string-encoded unicode, we can always decode a JSON string to valid UTF-8 as long as the string is well formed. That is wrong. If the user passes a Unicode filename it is expected to be translated to the current locale encoding for the purpose of, say, filename lookup. QEMU does not support anything but UTF-8. Since when? AFAICT, JSON string conversion is the only place where there is any dependency on UTF-8. Anything else should just work. That's pretty common with Unix software. I don't think any modern Unix platform actually uses UCS2 or UTF-16. It's either ascii or UTF-8. Most/all Linux distributions support UTF-8 as well as a zillion other encodings (single-byte ASCII + another charset, or multi-byte charsets for languages with many characters. Maybe there's some confusion here. UTF-8 is an encoding, not a locale. The common encodings are ASCII, UTF-8, UCS2, UTF-16, and UTF-32. ASCII is a character set and encoding. The rest are encodings for Unicode. There are lots of other encodings, say latin-1. An application has to explicitly support an encoding. It is not transparent. It is fully transparent until you do wire conversions (like we do with qmp which is explicitly UTF-8). UCS2/UTF-16 means that strings are not 'const char *'s but 'const wchar_t *' where typedef unsigned short wchar_t;. QEMU assumes, in lots of places that strings are single-byte NUL terminated. Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much tie you to ASCII/UTF-8. You can have a single NUL byte as part of a valid UCS2 string. We're tied to single- or multiple- byte encodings, and can't do wchar_t. But that's very different from ASCII/UTF-8 only. The only place it even matters is Windows and Windows has ASCII and UTF-16 versions of their APIs. So on Windows, non-ASCII characters won't be handled correctly (yet another one of the many issues with Windows support in QEMU). UTF-8 is self-recovering though so it degrades gracefully. It matters on Linux with el_GR.iso88597, for example. The whole series of iso8859 (8-bit encodings) are officially abandoned in favor of UCS and encodings that support the full UCS code page (UTF-8/UTF-16). I see no strong reason to try and support deprecated encodings when there are perfectly valid replacements like el_GR.utf8. All it takes is a call to iconv(3). I agree it's unlikely to happen in practice. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld vroze...@redhat.com wrote: On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn h...@univention.de wrote: Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt0 0.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov %rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub $0x20,%rsp 0xf8000c485a8a: mov %rcx,%rdi 0xf8000c485a8d: xor %ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc %ebx 0xf8000c485a92: test %ebx,0x274834(%rip) # 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov (%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne 0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov %ebx,%eax 0xf8000c485ab2: mov 0x30(%rsp),%rbx 0xf8000c485ab7: add $0x20,%rsp 0xf8000c485abb: pop %rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? Debugging installation-phase problems on 64-bit platforms is a very complicated thing. If the problem is reproducible on x86 platforms, you can try printing messages (RhelDbgPrint function) to localize the problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build checked (debug) version of the driver. Is that even possible - I thought these drivers need to be signed on recent versions of Windows? Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to
[PATCH] qemu-kvm: Remove merge artifact
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-stub.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kvm-stub.c b/kvm-stub.c
index caef9b4..fc2b810 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -137,7 +137,6 @@ int kvm_set_ioeventfd_mmio_long(int fd, uint32_t adr,
uint32_t val, bool assign)
return -ENOSYS;
}
- HEAD
int kvm_has_gsi_routing(void)
{
return 0;
--
1.7.1
--
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: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 14:26 +, Stefan Hajnoczi wrote: On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld vroze...@redhat.com wrote: On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn h...@univention.de wrote: Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian based system using AMD64 CPUs. During the install, the system froze (progress bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt00.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=1,cores=1,threads=1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=utc \ -boot dc \ -drive file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ -drive file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 \ -net tap,fd=20,vlan=0,name=hostnet0 \ -usb \ -device usb-tablet,id=input0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ -no-kvm-irqchip The -no-kvm-irqchip-Option was added, because we experienced shutdown/resume problems with other machines, which either received no interrupts anymore or where caught in their interrupt service routine, never being able to acknowledge the interrupts. Adding that option solved that problem, but might be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine, which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xf8000c485a80 0xf8000c485a80: mov%rbx,0x8(%rsp) 0xf8000c485a85: push %rdi 0xf8000c485a86: sub$0x20,%rsp 0xf8000c485a8a: mov%rcx,%rdi 0xf8000c485a8d: xor%ebx,%ebx 0xf8000c485a8f: nop 0xf8000c485a90: inc%ebx 0xf8000c485a92: test %ebx,0x274834(%rip)# 0xf8000c6fa2cc 0xf8000c485a98: je 0xf8000c48adad 0xf8000c485a9e: pause 0xf8000c485aa0: mov(%rdi),%rcx 0xf8000c485aa3: test %rcx,%rcx 0xf8000c485aa6: jne0xf8000c485a90 0xf8000c485aa8: lock btsq $0x0,(%rdi) 0xf8000c485aae: jb 0xf8000c485a90 0xf8000c485ab0: mov%ebx,%eax 0xf8000c485ab2: mov0x30(%rsp),%rbx 0xf8000c485ab7: add$0x20,%rsp 0xf8000c485abb: pop%rdi 0xf8000c485abc: retq (gdb) x/w 0xf8000c6fa2cc 0xf8000c6fa2cc: 0x (gdb) x/w $rdi 0xfa800131f600: 0x0001 Did someone experience similar problems or does somebody know if there was a fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO with Qcow2 images, which were using backing-files for copy-on-write: they just crashed with a blue-screen. Just changing from the CoW-qcow2 to the master-qcow2 file fixed the problem, but this isn't satisfactory, since we would like to use the CoW-functionality. Not using VirtIO also fixed the problem, but has performance penalties. Vadim: Any suggestions for extracting more relevant information in these cases? Debugging installation-phase problems on 64-bit platforms is a very complicated thing. If the problem is reproducible on x86 platforms, you can try printing messages (RhelDbgPrint function) to localize the problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build checked (debug) version of the driver. Is that
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
Hello, Am Donnerstag 17 Februar 2011 13:45:34 schrieb Vadim Rozenfeld: On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: Why is is linked to virtio? Does install on ide work? Yes, works without the VirtIO block driver using IDE. Does install work without -no-kvm-irqchip (which had pretty serious problem till now)? Adding -no-kvm-irqchip usually does not solve problems, but just exchange one set of bugs to the other (and reduces performance drastically). I'll try again without -no-kvm-irqchip, newer KVM and newer Kernel, but last time I tested kvm-0.13 and Linux-2.6.37 with the same results, see http://article.gmane.org/gmane.comp.emulators.kvm.devel/66069 Does it work on Win7-32? :) I also had problems with Windows XP 32Bit: Installation taking more than 20 minutes with no noticeable progress, also VirtIO (probably an older version, I don't have that instance any more) BYtE Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ ** Besuchen Sie uns auf der CeBIT in Hannover ** ** Auf dem Univention Stand D36 in Halle 2** ** Vom 01. bis 05. März 2011 ** signature.asc Description: This is a digitally signed message part.
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 16:27 +0100, Philipp Hahn wrote: Hello, Am Donnerstag 17 Februar 2011 13:45:34 schrieb Vadim Rozenfeld: On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: Why is is linked to virtio? Does install on ide work? Yes, works without the VirtIO block driver using IDE. Does install work without -no-kvm-irqchip (which had pretty serious problem till now)? Adding -no-kvm-irqchip usually does not solve problems, but just exchange one set of bugs to the other (and reduces performance drastically). I'll try again without -no-kvm-irqchip, newer KVM and newer Kernel, but last time I tested kvm-0.13 and Linux-2.6.37 with the same results, see http://article.gmane.org/gmane.comp.emulators.kvm.devel/66069 Does it work on Win7-32? :) I also had problems with Windows XP 32Bit: Installation taking more than 20 minutes with no noticeable progress, also VirtIO (probably an older version, I don't have that instance any more) Could you please try cache=writethrough on virtio drive? Best regards, Vadim BYtE Philipp -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: VMX: Short circuit STI; HLT while an interrupt is pending
On Thu, Feb 17, 2011 at 11:12:43AM +0200, Avi Kivity wrote:
index ee1cd1a..541da0e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3437,6 +3437,15 @@ static int handle_interrupt_window(struct
kvm_vcpu *vcpu)
static int handle_halt(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction(vcpu);
+/*
+ * Short-circuit an STI; HLT sequence while an interrupt is
pending:
+ * instead of halting, re-entering the guest, and exiting
immediately
+ * on an interrupt window exit, go directly to the last step.
+ */
+if ((to_vmx(vcpu)-cpu_based_vm_exec_control
+ CPU_BASED_VIRTUAL_INTR_PENDING)
+ (kvm_get_rflags(vcpu) X86_EFLAGS_IF))
+return handle_interrupt_window(vcpu);
return kvm_emulate_halt(vcpu);
}
Why does the normal vcpu entry path fails to inject the interrupt?
Because after halt,
KVM_REQ_EVENT is not set?
Yes. Also, we want to clear CPU_BASED_VIRTUAL_INTR_PENDING.
Is there a reason why it cannot be handled in the main loop?
Don't follow. What are you suggesting?
That vcpu main loop (inject_pending_events etc) should be able to inject
the interrupt and clear interrupt exiting, instead of a short circuit
in specific exit handlers, as an improvement on top of the current
patchset. Any numbers, BTW?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback
On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
The current way of injecting MCE events without updating of and
synchronizing with the CPUState is broken and causes spurious
corruptions of the MCE-related parts of the CPUState.
Can you explain how? The current pronlem with MCE is that it bypasses
writeback code, but corruption has nothing to do with that.
As a first step towards a fix, enhance the state writeback code with
support for injecting events that are pending in the CPUState. A pending
exception will then be signaled via cpu_interrupt(CPU_INTERRUPT_MCE).
And, just like for TCG, we need to leave the halt state when
CPU_INTERRUPT_MCE is pending (left broken for the to-be-removed old KVM
code).
This will also allow to unify TCG and KVM injection code.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
target-i386/kvm.c | 75 +---
1 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index f909661..46f45db 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -467,6 +467,44 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank,
uint64_t status,
#endif /* !KVM_CAP_MCE*/
}
+static int kvm_inject_mce_oldstyle(CPUState *env)
+{
+#ifdef KVM_CAP_MCE
+if (kvm_has_vcpu_events()) {
+return 0;
+}
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+unsigned int bank, bank_num = env-mcg_cap 0xff;
+struct kvm_x86_mce mce;
+
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+
+/*
+ * There must be at least one bank in use if CPU_INTERRUPT_MCE was
set.
+ * Find it and use its values for the event injection.
+ */
+for (bank = 0; bank bank_num; bank++) {
+if (env-mce_banks[bank * 4 + 1] MCI_STATUS_VAL) {
+break;
+}
+}
+assert(bank bank_num);
+
+mce.bank = bank;
+mce.status = env-mce_banks[bank * 4 + 1];
+mce.mcg_status = env-mcg_status;
+mce.addr = env-mce_banks[bank * 4 + 2];
+mce.misc = env-mce_banks[bank * 4 + 3];
+
+return kvm_vcpu_ioctl(env, KVM_X86_SET_MCE, mce);
+}
+#endif /* KVM_CAP_MCE */
+return 0;
+}
+
static void cpu_update_state(void *opaque, int running, int reason)
{
CPUState *env = opaque;
@@ -1375,10 +1413,25 @@ static int kvm_put_vcpu_events(CPUState *env, int
level)
return 0;
}
-events.exception.injected = (env-exception_injected = 0);
-events.exception.nr = env-exception_injected;
-events.exception.has_error_code = env-has_error_code;
-events.exception.error_code = env-error_code;
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+if (env-exception_injected == EXCP08_DBLE) {
+/* this means triple fault */
+qemu_system_reset_request();
+env-exit_request = 1;
+}
+events.exception.injected = 1;
+events.exception.nr = EXCP12_MCHK;
+events.exception.has_error_code = 0;
+} else {
+events.exception.injected = (env-exception_injected = 0);
+events.exception.nr = env-exception_injected;
+events.exception.has_error_code = env-has_error_code;
+events.exception.error_code = env-error_code;
+}
IMO it is important to maintain a scope for kvm_put_vcpu_events /
kvm_get_vcpu_events: they synchronize state to/from the kernel. Not more
than that. Whatever you're trying to do here should be higher in the
vcpu loop code.
events.interrupt.injected = (env-interrupt_injected = 0);
events.interrupt.nr = env-interrupt_injected;
@@ -1539,6 +1592,11 @@ int kvm_arch_put_registers(CPUState *env, int level)
if (ret 0) {
return ret;
}
+/* must be before kvm_put_msrs */
+ret = kvm_inject_mce_oldstyle(env);
+if (ret 0) {
+return ret;
+}
ret = kvm_put_msrs(env, level);
if (ret 0) {
return ret;
@@ -1678,10 +1736,17 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run
*run)
int kvm_arch_process_irqchip_events(CPUState *env)
{
if (kvm_irqchip_in_kernel()) {
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+kvm_cpu_synchronize_state(env);
+if (env-mp_state == KVM_MP_STATE_HALTED) {
+env-mp_state = KVM_MP_STATE_RUNNABLE;
+}
+}
Should not manipulate mp_state of a running vcpu (should only do that
for
Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback
On 2011-02-17 17:35, Marcelo Tosatti wrote:
On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
The current way of injecting MCE events without updating of and
synchronizing with the CPUState is broken and causes spurious
corruptions of the MCE-related parts of the CPUState.
Can you explain how? The current pronlem with MCE is that it bypasses
writeback code, but corruption has nothing to do with that.
It's precisely the same scenario as with the old debug exception
re-injection: If we update the pending exception state via
KVM_SET_VCPU_EVENTS, we must not inject it via any other path. Otherwise
we end up with overwritten/lost events - which is extremely critical for
this rarely taken code paths.
Jut like parts of KVM_SET_GUEST_DEBUG, KVM_X86_SET_MCE pre-dates
KVM_SET_VCPU_EVENTS which obsoleted all other exception injection
mechanisms.
As a first step towards a fix, enhance the state writeback code with
support for injecting events that are pending in the CPUState. A pending
exception will then be signaled via cpu_interrupt(CPU_INTERRUPT_MCE).
And, just like for TCG, we need to leave the halt state when
CPU_INTERRUPT_MCE is pending (left broken for the to-be-removed old KVM
code).
This will also allow to unify TCG and KVM injection code.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
target-i386/kvm.c | 75
+---
1 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index f909661..46f45db 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -467,6 +467,44 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank,
uint64_t status,
#endif /* !KVM_CAP_MCE*/
}
+static int kvm_inject_mce_oldstyle(CPUState *env)
+{
+#ifdef KVM_CAP_MCE
+if (kvm_has_vcpu_events()) {
+return 0;
+}
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+unsigned int bank, bank_num = env-mcg_cap 0xff;
+struct kvm_x86_mce mce;
+
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+
+/*
+ * There must be at least one bank in use if CPU_INTERRUPT_MCE was
set.
+ * Find it and use its values for the event injection.
+ */
+for (bank = 0; bank bank_num; bank++) {
+if (env-mce_banks[bank * 4 + 1] MCI_STATUS_VAL) {
+break;
+}
+}
+assert(bank bank_num);
+
+mce.bank = bank;
+mce.status = env-mce_banks[bank * 4 + 1];
+mce.mcg_status = env-mcg_status;
+mce.addr = env-mce_banks[bank * 4 + 2];
+mce.misc = env-mce_banks[bank * 4 + 3];
+
+return kvm_vcpu_ioctl(env, KVM_X86_SET_MCE, mce);
+}
+#endif /* KVM_CAP_MCE */
+return 0;
+}
+
static void cpu_update_state(void *opaque, int running, int reason)
{
CPUState *env = opaque;
@@ -1375,10 +1413,25 @@ static int kvm_put_vcpu_events(CPUState *env, int
level)
return 0;
}
-events.exception.injected = (env-exception_injected = 0);
-events.exception.nr = env-exception_injected;
-events.exception.has_error_code = env-has_error_code;
-events.exception.error_code = env-error_code;
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+if (env-exception_injected == EXCP08_DBLE) {
+/* this means triple fault */
+qemu_system_reset_request();
+env-exit_request = 1;
+}
+events.exception.injected = 1;
+events.exception.nr = EXCP12_MCHK;
+events.exception.has_error_code = 0;
+} else {
+events.exception.injected = (env-exception_injected = 0);
+events.exception.nr = env-exception_injected;
+events.exception.has_error_code = env-has_error_code;
+events.exception.error_code = env-error_code;
+}
IMO it is important to maintain a scope for kvm_put_vcpu_events /
kvm_get_vcpu_events: they synchronize state to/from the kernel. Not more
than that. Whatever you're trying to do here should be higher in the
vcpu loop code.
We pick up CPU_INTERRUPT_MCE and translate it into the right exception
that put_vcpu_events is about to sync to the kernel. What should be done
earlier of those steps? Calculating env-exception_injected?
events.interrupt.injected = (env-interrupt_injected = 0);
events.interrupt.nr = env-interrupt_injected;
@@ -1539,6 +1592,11 @@ int kvm_arch_put_registers(CPUState *env, int level)
if (ret 0) {
return ret;
}
+
[KVM-AUTOTEST PATCH 2/4] KVM test: kvm_config.py: allow 'include' when parsing strings
Currently 'include' is only allowed when parsing a file. This patch allows it to be used when parsing a string as well. Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_config.py |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py index cab0022..27c3171 100755 --- a/client/tests/kvm/kvm_config.py +++ b/client/tests/kvm/kvm_config.py @@ -441,11 +441,10 @@ class Parser(object): if len(words) 2: raise ParserError(Syntax error: missing parameter, line, cr.filename, linenum) -if not isinstance(cr, FileReader): -raise ParserError(Cannot include because no file is - currently open, - line, cr.filename, linenum) -filename = os.path.join(os.path.dirname(cr.filename), words[1]) +filename = os.path.expanduser(words[1]) +if isinstance(cr, FileReader) and not os.path.isabs(filename): +filename = os.path.join(os.path.dirname(cr.filename), +filename) if not os.path.isfile(filename): self._warn(%r (%s:%s): file doesn't exist or is not a regular file, line, cr.filename, linenum) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 3/4] KVM test: kvm_config.py: remove unnecessary 'string' import
Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_config.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py index 27c3171..60df208 100755 --- a/client/tests/kvm/kvm_config.py +++ b/client/tests/kvm/kvm_config.py @@ -5,7 +5,7 @@ KVM test configuration file parser @copyright: Red Hat 2008-2011 -import re, os, sys, optparse, collections, string +import re, os, sys, optparse, collections # Filter syntax: -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 4/4] KVM test: kvm_config.py: correct docstring of get_next_line()
Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_config.py |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py index 60df208..a125129 100755 --- a/client/tests/kvm/kvm_config.py +++ b/client/tests/kvm/kvm_config.py @@ -607,8 +607,7 @@ class StrReader(object): def get_next_line(self, prev_indent): -Get the next non-empty, non-comment line in the string, whose -indentation level is higher than prev_indent. +Get the next line in the current block. @param prev_indent: The indentation level of the previous block. @return: (line, indent, linenum), where indent is the line's -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 1/4] KVM test: kvm_config.py: parse extra strings passed as command line args
This allows to quickly see the effect of some extra code, e.g.
./kvm_config.py tests.cfg only my_set no qcow2
The given strings may contain newlines.
Signed-off-by: Michael Goldish mgold...@redhat.com
---
client/tests/kvm/kvm_config.py |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py
index 807a204..cab0022 100755
--- a/client/tests/kvm/kvm_config.py
+++ b/client/tests/kvm/kvm_config.py
@@ -640,7 +640,9 @@ class FileReader(StrReader):
if __name__ == __main__:
-parser = optparse.OptionParser(usage: %prog [options] filename)
+parser = optparse.OptionParser('usage: %prog [options] filename '
+ '[extra code] ...\n\nExample:\n\n'
+ '%prog tests.cfg only my_set no qcow2')
parser.add_option(-v, --verbose, dest=debug, action=store_true,
help=include debug messages in console output)
parser.add_option(-f, --fullname, dest=fullname, action=store_true,
@@ -653,6 +655,9 @@ if __name__ == __main__:
parser.error(filename required)
c = Parser(args[0], debug=options.debug)
+for s in args[1:]:
+c.parse_string(s)
+
for i, d in enumerate(c.get_dicts()):
if options.fullname:
print dict %4d: %s % (i + 1, d[name])
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback
On Thu, Feb 17, 2011 at 06:06:19PM +0100, Jan Kiszka wrote:
On 2011-02-17 17:35, Marcelo Tosatti wrote:
On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
The current way of injecting MCE events without updating of and
synchronizing with the CPUState is broken and causes spurious
corruptions of the MCE-related parts of the CPUState.
Can you explain how? The current pronlem with MCE is that it bypasses
writeback code, but corruption has nothing to do with that.
It's precisely the same scenario as with the old debug exception
re-injection: If we update the pending exception state via
KVM_SET_VCPU_EVENTS, we must not inject it via any other path. Otherwise
we end up with overwritten/lost events - which is extremely critical for
this rarely taken code paths.
Jut like parts of KVM_SET_GUEST_DEBUG, KVM_X86_SET_MCE pre-dates
KVM_SET_VCPU_EVENTS which obsoleted all other exception injection
mechanisms.
OK.
As a first step towards a fix, enhance the state writeback code with
support for injecting events that are pending in the CPUState. A pending
exception will then be signaled via cpu_interrupt(CPU_INTERRUPT_MCE).
And, just like for TCG, we need to leave the halt state when
CPU_INTERRUPT_MCE is pending (left broken for the to-be-removed old KVM
code).
This will also allow to unify TCG and KVM injection code.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
target-i386/kvm.c | 75
+---
1 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index f909661..46f45db 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -467,6 +467,44 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank,
uint64_t status,
#endif /* !KVM_CAP_MCE*/
}
+static int kvm_inject_mce_oldstyle(CPUState *env)
+{
+#ifdef KVM_CAP_MCE
+if (kvm_has_vcpu_events()) {
+return 0;
+}
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+unsigned int bank, bank_num = env-mcg_cap 0xff;
+struct kvm_x86_mce mce;
+
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+
+/*
+ * There must be at least one bank in use if CPU_INTERRUPT_MCE
was set.
+ * Find it and use its values for the event injection.
+ */
+for (bank = 0; bank bank_num; bank++) {
+if (env-mce_banks[bank * 4 + 1] MCI_STATUS_VAL) {
+break;
+}
+}
+assert(bank bank_num);
+
+mce.bank = bank;
+mce.status = env-mce_banks[bank * 4 + 1];
+mce.mcg_status = env-mcg_status;
+mce.addr = env-mce_banks[bank * 4 + 2];
+mce.misc = env-mce_banks[bank * 4 + 3];
+
+return kvm_vcpu_ioctl(env, KVM_X86_SET_MCE, mce);
+}
+#endif /* KVM_CAP_MCE */
+return 0;
+}
+
static void cpu_update_state(void *opaque, int running, int reason)
{
CPUState *env = opaque;
@@ -1375,10 +1413,25 @@ static int kvm_put_vcpu_events(CPUState *env, int
level)
return 0;
}
-events.exception.injected = (env-exception_injected = 0);
-events.exception.nr = env-exception_injected;
-events.exception.has_error_code = env-has_error_code;
-events.exception.error_code = env-error_code;
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+if (env-exception_injected == EXCP08_DBLE) {
+/* this means triple fault */
+qemu_system_reset_request();
+env-exit_request = 1;
+}
+events.exception.injected = 1;
+events.exception.nr = EXCP12_MCHK;
+events.exception.has_error_code = 0;
+} else {
+events.exception.injected = (env-exception_injected = 0);
+events.exception.nr = env-exception_injected;
+events.exception.has_error_code = env-has_error_code;
+events.exception.error_code = env-error_code;
+}
IMO it is important to maintain a scope for kvm_put_vcpu_events /
kvm_get_vcpu_events: they synchronize state to/from the kernel. Not more
than that. Whatever you're trying to do here should be higher in the
vcpu loop code.
We pick up CPU_INTERRUPT_MCE and translate it into the right exception
that put_vcpu_events is about to sync to the kernel. What should be done
earlier of those steps? Calculating env-exception_injected?
Everything but writeback. Update env-exception_injected/nr in
Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback
On 2011-02-17 18:55, Marcelo Tosatti wrote:
@@ -1375,10 +1413,25 @@ static int kvm_put_vcpu_events(CPUState *env, int
level)
return 0;
}
-events.exception.injected = (env-exception_injected = 0);
-events.exception.nr = env-exception_injected;
-events.exception.has_error_code = env-has_error_code;
-events.exception.error_code = env-error_code;
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+if (env-exception_injected == EXCP08_DBLE) {
+/* this means triple fault */
+qemu_system_reset_request();
+env-exit_request = 1;
+}
+events.exception.injected = 1;
+events.exception.nr = EXCP12_MCHK;
+events.exception.has_error_code = 0;
+} else {
+events.exception.injected = (env-exception_injected = 0);
+events.exception.nr = env-exception_injected;
+events.exception.has_error_code = env-has_error_code;
+events.exception.error_code = env-error_code;
+}
IMO it is important to maintain a scope for kvm_put_vcpu_events /
kvm_get_vcpu_events: they synchronize state to/from the kernel. Not more
than that. Whatever you're trying to do here should be higher in the
vcpu loop code.
We pick up CPU_INTERRUPT_MCE and translate it into the right exception
that put_vcpu_events is about to sync to the kernel. What should be done
earlier of those steps? Calculating env-exception_injected?
Everything but writeback. Update env-exception_injected/nr in
process_irqchip_events, or in a separate kvm_arch_update_exceptions.
OK, will rework this.
return ret;
@@ -1678,10 +1736,17 @@ void kvm_arch_post_run(CPUState *env, struct
kvm_run *run)
int kvm_arch_process_irqchip_events(CPUState *env)
{
if (kvm_irqchip_in_kernel()) {
+if (env-interrupt_request CPU_INTERRUPT_MCE) {
+kvm_cpu_synchronize_state(env);
+if (env-mp_state == KVM_MP_STATE_HALTED) {
+env-mp_state = KVM_MP_STATE_RUNNABLE;
+}
+}
Should not manipulate mp_state of a running vcpu (should only do that
for migration when vcpu is stopped), since its managed by the kernel,
for irqchip case.
Not for asynchronously injected MCEs. The target CPU would simply
oversleep them. MCEs are not in the scope of the in-kernel irqchip.
Pending MCE exception could break out of in-kernel halt emulation.
Can't follow. What do you mean? That the kernel already takes care? I
didn't find a trace, so I added that code.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] kvm: x86: Consolidate TCG and KVM MCE injection code
On Tue, Feb 15, 2011 at 09:23:33AM +0100, Jan Kiszka wrote: This switches KVM's MCE injection path to cpu_x86_inject_mce, both for SIGBUS and monitor initiated events. This means we prepare the MCA MSRs in the VCPUState also for KVM. We have to drop the MSRs writeback restrictions for this purpose which is now safe as every uncoordinated MSR injection is removed with this patch. We have to execute every per-VCPU event setup on the target VCPU as we are performing a read-modify-write on its state. Signed-off-by: Jan Kiszka jan.kis...@siemens.com CC: Huang Ying ying.hu...@intel.com CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com CC: Jin Dongming jin.dongm...@np.css.fujitsu.com Difficult to review, please split: - drop writeback restriction - unify monitor/sigbus injection paths - cleanup / refactor -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] kvm: x86: Consolidate TCG and KVM MCE injection code
On 2011-02-17 19:08, Marcelo Tosatti wrote: On Tue, Feb 15, 2011 at 09:23:33AM +0100, Jan Kiszka wrote: This switches KVM's MCE injection path to cpu_x86_inject_mce, both for SIGBUS and monitor initiated events. This means we prepare the MCA MSRs in the VCPUState also for KVM. We have to drop the MSRs writeback restrictions for this purpose which is now safe as every uncoordinated MSR injection is removed with this patch. We have to execute every per-VCPU event setup on the target VCPU as we are performing a read-modify-write on its state. Signed-off-by: Jan Kiszka jan.kis...@siemens.com CC: Huang Ying ying.hu...@intel.com CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com CC: Jin Dongming jin.dongm...@np.css.fujitsu.com Difficult to review, please split: - drop writeback restriction That will not work due to mutual dependency (see changelog)... - unify monitor/sigbus injection paths - cleanup / refactor ...but I will check again and filter out potential cleanups that could be done afterwards. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback
On Thu, Feb 17, 2011 at 07:04:51PM +0100, Jan Kiszka wrote: Should not manipulate mp_state of a running vcpu (should only do that for migration when vcpu is stopped), since its managed by the kernel, for irqchip case. Not for asynchronously injected MCEs. The target CPU would simply oversleep them. MCEs are not in the scope of the in-kernel irqchip. Pending MCE exception could break out of in-kernel halt emulation. Can't follow. What do you mean? That the kernel already takes care? I didn't find a trace, so I added that code. Nevermind. This is rare and halted - running transition in userspace is harmless. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 00/31] [PULL] qemu-kvm.git uq/master queue
On 01/24/2011 03:02 AM, Marcelo Tosatti wrote: The following changes since commit b646968336d4180bdd7d2e24209708dcee6ba400: checkpatch: adjust to QEMUisms (2011-01-20 20:58:56 +) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Jan Kiszka (23): kvm: x86: Fix DPL write back of segment registers kvm: x86: Remove obsolete SS.RPL/DPL aligment kvm: x86: Prevent sign extension of DR7 in guest debugging mode kvm: x86: Fix a few coding style violations kvm: Fix coding style violations kvm: x86: Swallow KVM_EXIT_SET_TPR kvm: Stop on all fatal exit reasons kvm: Improve reporting of fatal errors x86: Optionally dump code bytes on cpu_dump_state kvm: x86: Align kvm_arch_put_registers code with comment kvm: x86: Prepare kvm_get_mp_state for in-kernel irqchip kvm: x86: Remove redundant mp_state initialization kvm: x86: Fix xcr0 reset mismerge kvm: x86: Refactor msr_star/hsave_pa setup and checks kvm: x86: Reset paravirtual MSRs kvm: x86: Fix !CONFIG_KVM_PARA build kvm: Drop smp_cpus argument from init functions kvm: Consolidate must-have capability checks kvm: x86: Rework identity map and TSS setup for larger BIOS sizes kvm: Flush coalesced mmio buffer on IO window exits kvm: Do not use qemu_fair_mutex kvm: x86: Implicitly clear nmi_injected/pending on reset kvm: x86: Only read/write MSR_KVM_ASYNC_PF_EN if supported Pulled, but this last change broke the build on 2.6.32. I applied a one line fix to have another #ifdef KVM_CAP_ASYNC_PF_EN to resolve it. Regards, Anthony Liguori Jin Dongming (6): Clean up cpu_inject_x86_mce() Add broadcast option for mce command Add function for checking mca broadcast of CPU kvm: introduce kvm_mce_in_progress kvm: kvm_mce_inj_* subroutines for templated error injections kvm: introduce kvm_inject_x86_mce_on Lai Jiangshan (2): kvm: Enable user space NMI injection for kvm guest kvm: convert kvm_ioctl(KVM_CHECK_EXTENSION) to kvm_check_extension() configure | 36 ++- cpu-all.h |5 +- cpus.c|2 - hmp-commands.hx |6 +- kvm-all.c | 247 + kvm-stub.c|2 +- kvm.h | 14 +- monitor.c |7 +- target-i386/cpu.h |9 +- target-i386/cpuid.c |5 +- target-i386/helper.c | 97 ++- target-i386/kvm.c | 749 +++- target-i386/kvm_x86.h |5 +- target-ppc/kvm.c | 10 +- target-s390x/kvm.c|6 +- vl.c |2 +- 16 files changed, 714 insertions(+), 488 deletions(-) -- 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: Passthrough of 2 PCI devices works 80% (Kernel 2.6.37, Debian Squeeze, Win7 VM)
i`ve got a question about pci passthrogh of 2 pci devices (2x DVB-S2 PCI cards with Saa7146 PCI Bridge from Technotrend: S2-3200). I am using squeeze with a 2.6.37 selfcompiled Kernel. I want to passthrough both devices to a virtual machine (Win7) an get problems. If i passthrough one device (other is unplugged) it works flawlessly. I'm glad to hear it works one at a time. It's oddly specific that you mention it works if the other card is unplugged, can you only physically have one card plugged in at a time for it to work (ie. if you have both cards physically installed, but only one assigned to the guest, does it work)? Can you simultaneously assign each card to separate guests and they work? I tried both devices, one at a time. Both are working well. KVM supports the passthrough with all devices together behind a bridge only. So i have to pass all 03.0x.y devices through to one guest only. The time i add both devices and pass them through i am still able to start the VM and i don`t see anything in the error logs. Even Windows7 or XP detects both cards and installs the driver correctly (actual BDA Driver, standard broadcast video driver). But the time i want to acces the cards, i get a BSOD - caused by the driver. I'll toss out a dumb question, can the drivers for Win7 or WinXP drive two cards when running on bare metal? Does a Linux guest work with both cards better? The driver support more than one devices. I already contacted the support and they assured me, that the driver i used is working. Using both cards in Linux won`t help, because i want to use them with a windows application. I already aligned the io memory of both devices, checked the libvirt logs, kernel and syslogs - there is nothing for a kvm newbe that seems to be odd. The kernel is compiled with all the mentioned kernel options of the linux-kvm.org page - except that i compiled the stub driver as module. One card alone (both tried separately) is working w/o any flaws. Kvm is able to pass through all devices behind a PCI Bridge - so take a look at the 03:0x.0 devices below: i use those 2 sat boards only in 3 PCI slots. What am i able to do to make deeper analysis or to solve the problem ? If each card works when assigned separately and you can boot the guest with both cards assign and the drivers load and device manager isn't reporting any errors, I'd lean towards a Windows driver issue. There is some debugging you can enable in hw/device-assignment.c that might shed some light on what the drivers is trying to do before the BSOD. What error is the BSOD reporting? Are you using the latest qemu-kvm.git? The drivers work on 'bare metal' as you mentioned above. I won`t believe that its a pure driver-only issue for now. But the other behavior of the passed through device may cause the driver fault. The BSOD tells, that it is a general driver issue which caused the fault. I am using the kvm codse which is distributed in the kernel 2.6.37 and standard debian squeeze repositories for installation of the tools lib-virt, etc... I am trying to get some more PCI spcecific data from the windows guests. I will try to use both cards in a linux vm. Thanks, Alex Thanks for participating in my very special problem, DP -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: ppc: Fix breakage of kvm_arch_pre_run/process_irqchip_events
On 2011-02-07 12:19, Jan Kiszka wrote:
We do not check them, and the only arch with non-empty implementations
always returns 0 (this is also true for qemu-kvm).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Alexander Graf ag...@suse.de
---
kvm.h |5 ++---
target-i386/kvm.c |8 ++--
target-ppc/kvm.c |6 ++
target-s390x/kvm.c |6 ++
4 files changed, 8 insertions(+), 17 deletions(-)
...
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 93ecc57..bd4012a 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -256,14 +256,12 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
return 0;
}
-int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
-return 0;
}
-int kvm_arch_process_irqchip_events(CPUState *env)
+void kvm_arch_process_irqchip_events(CPUState *env)
{
-return 0;
}
Oops. Do we already have a built-bot for KVM-enabled PPC (and s390)
targets somewhere?
Jan
---8--
From: Jan Kiszka jan.kis...@siemens.com
Commit 7a39fe5882 failed to convert the right arch function.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-ppc/kvm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index bd4012a..3924f4b 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -222,7 +222,7 @@ int kvmppc_set_interrupt(CPUState *env, int irq, int level)
#define PPC_INPUT_INT PPC6xx_INPUT_INT
#endif
-int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
{
int r;
unsigned irq;
@@ -253,15 +253,15 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
/* We don't know if there are more interrupts pending after this. However,
* the guest will return to userspace in the course of handling this one
* anyways, so we will get a chance to deliver the rest. */
-return 0;
}
void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
}
-void kvm_arch_process_irqchip_events(CPUState *env)
+int kvm_arch_process_irqchip_events(CPUState *env)
{
+return 0;
}
static int kvmppc_handle_halt(CPUState *env)
--
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: Passthrough of 2 PCI devices works 80% (Kernel 2.6.37, Debian Squeeze, Win7 VM)
I extracted some WindowsXPpro VM PCI data with pcitree - maybe this gives you a hint: IRQ Mapping: INT line 0 - INT line 1 - INT line 2 - INT line 3 - INT line 4 - INT line 5 - 5-A(0.3.0)1000.1AF45-A(0.7.0)7146.1131 INT line 6 - INT line 7 - INT line 8 - INT line 9 - 9-A(0.1.3)7113.8086 INT line 10 - 10-D(0.1.2)7020.8086 10-A(0.4.0)1001.1AF4 10-A(0.6.0)1002.1AF4 INT line 11 - 11-A(0.5.0)7146.1131 INT line 12 - INT line 13 - INT line 14 - INT line 15 - IO memory Map: F000 - : BAR1(0.2.0)15AD.0405 F080 - : F100 - : BAR2(0.2.0)15AD.0405BAR1(0.3.0)1AF4.1000 BAR0(0.5.0)1131.7146BAR0(0.7.0)1131.7146 host CPU : 0.00.0Host/PCI; Bridge Device 8086 1237 [Intel] 82440/1FX 440FX ´(Natoma) System Controller: 82440/1FX 440FX (Natoma) System Controller // SubIDs 1af4 1100 no-name: no-name 1237 8086 00 : DID VID 0003 04 : Stat Cmd 0600 0002 08 : BaseClass SubClass PgmIF RevID 0C : BIST Header LatTimer CacheLSize 10 : BAR 0 14 : BAR 1 18 : BAR 2 1C : BAR 3 20 : BAR 4 24 : BAR 5 28 : Cardbus_CIS_Ptr 1100 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 3C : maxLat minGnt IntPin IntLine : 0.01.0PCI/ISA; Bridge Device 8086 7000 [Intel] 82371SB PIIX3 ISA Bridge: 82371SB PIIX3 ISA Bridge // SubIDs 1af4 1100 no-name: no-name 7000 8086 00 : DID VID 0200 0007 04 : Stat Cmd 0601 08 : BaseClass SubClass PgmIF RevID 0080 0C : BIST Header LatTimer CacheLSize 10 : BAR 0 14 : BAR 1 18 : BAR 2 1C : BAR 3 20 : BAR 4 24 : BAR 5 28 : Cardbus_CIS_Ptr 1100 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 3C : maxLat minGnt IntPin IntLine : 0.01.1o. Mass Storage Controller 8086 7010 [Intel] 82371SB PIIX3 EIDE Controller: 82371SB PIIX3 EIDE Controller // SubIDs 1af4 1100 no-name: no-name 7010 8086 00 : DID VID 0280 0007 04 : Stat Cmd 0101 8000 08 : BaseClass SubClass PgmIF RevID 0C : BIST Header LatTimer CacheLSize 10 : BAR 0 14 : BAR 1 18 : BAR 2 1C : BAR 3 C001 20 : BAR 4 io 24 : BAR 5 28 : Cardbus_CIS_Ptr 1100 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 3C : maxLat minGnt IntPin IntLine : 0.01.2Universal Host Controller; USB (Universal Serial Bus); Serial Bus Controller 8086 7020 [Intel] 82371SB PIIX3 USB Controller: 82371SB PIIX3 USB Controller // SubIDs 1af4 1100 no-name: no-name 7020 8086 00 : DID VID 0007 04 : Stat Cmd 0C03 0001 08 : BaseClass SubClass PgmIF RevID 0C : BIST Header LatTimer CacheLSize 10 : BAR 0 14 : BAR 1 18 : BAR 2 1C : BAR 3 C021 20 : BAR 4 io 24 : BAR 5 28 : Cardbus_CIS_Ptr 1100 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 040A 3C : maxLat minGnt IntPin IntLine : 0.01.3Other; Bridge Device 8086 7113 [Intel] 82371AB/EB/MB PIIX4/E/M Power Management Controller: 82371AB/EB/MB PIIX4/E/M Power Management Controller // SubIDs 1af4 1100 no-name: no-name 7113 8086 00 : DID VID 0280 0003 04 : Stat Cmd 0680 0003 08 : BaseClass SubClass PgmIF RevID 0C : BIST Header LatTimer CacheLSize 10 : BAR 0 14 : BAR 1 18 : BAR 2 1C : BAR 3 20 : BAR 4 24 : BAR 5 28 : Cardbus_CIS_Ptr 1100 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 0109 3C : maxLat minGnt IntPin IntLine : 0.02.0VGA; PC Compatible; Display Controller 15ad 0405 [VMware] VGA 4.0.5: VGA 4.0.5 // SubIDs 15ad 0405 VGA 4.0.5: VGA 4.0.5 0405 15AD 00 : DID VID 0007 04 : Stat Cmd 0300 08 : BaseClass SubClass PgmIF RevID 4000 0C : BIST Header LatTimer CacheLSize C041 10 : BAR 0 io F000 0008 14 : BAR 1 mem pref. 32bit F100 0008 18 : BAR 2 mem pref. 32bit 1C : BAR 3 20 : BAR 4 24 : BAR 5 28 : Cardbus_CIS_Ptr 0405 15AD 2C : SubID SubVendorID 30 : Exp_ROM_BAR 34 : reserved 38 : reserved 3C : maxLat minGnt IntPin IntLine : 0.03.0Ethernet; Network Controller 1af4 1000 [no VID] no device name found: no device description found // SubIDs 1af4 0001 no-name: no-name 1000 1AF4 00 : DID VID 0010 0007 04 : Stat Cmd 0200 08 : BaseClass SubClass PgmIF RevID 0C : BIST Header LatTimer CacheLSize C061 10 : BAR 0 io F101 14 : BAR 1 mem 32bit 18 : BAR 2 1C : BAR 3 20 : BAR 4 24 : BAR 5 28 : Cardbus_CIS_Ptr 0001 1AF4 2C : SubID SubVendorID 30 : Exp_ROM_BAR 0040 34 : reserved
[Bug 29232] [VT-d] VT-d device passthrough fail to guest
https://bugzilla.kernel.org/show_bug.cgi?id=29232 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added CC||flor...@mickler.org, ||maciej.rute...@gmail.com, ||r...@sisk.pl Kernel Version||2.6.38-rc4 Version|unspecified |2.5 Blocks||27352 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/745 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_debian_5_0
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/746 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_x86_64_out_of_tree
The Buildbot has detected a new failure of disable_kvm_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/694 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_out_of_tree
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/694 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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] Re: QEMU-KVM and video performance - Update
Hello, Some update on this issue, archive: http://www.mail-archive.com/kvm@vger.kernel.org/msg32600.html Seems to be that cirrus VGA is now ok (1000MB/s up to 2000MB/s). But cirrus has only 320x200x256colors (Mode 13h) mode implemented in VESA BIOS. VMWare and std VGA still have the performance issue. I guess improvement is related to the following commit: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=0d14905b5eb8aa1c2e195e13478bb7c74e1776db Especially i guess the change in hw/cirrus_vga.c. Any idea how to fix: 1.) More VESA modes in cirrus VGA (is VESA emulation done by Seabios or by KVM cirrus BIOS?) 2.) fix in VMWare and std VGA modes the performance, too Versions are latest dev versions of KVM user part and Seabios from GIT. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Wed, 12 May 2010, Avi Kivity wrote: On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote: On Mon, 10 May 2010, Avi Kivity wrote: On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote: For 256 color more the first priority is to find out why direct mapping is not used. I'd suggest tracing the code that makes this decision (in hw/*vga.c) and seeing if it's right or not. I think this is because A000 is not initialized for KVM (see log below and logging patch attached). Why isn't it initialized? Did the guest configure things such as it is impossible to map it directly? Or does the configuration allow direct mapping and qemu incorrectly decides that it cannot direct map? Best would be to print out all the configuration registers and interpret them according to the specification. vga_dirty_log_start vga_dirty_log_start_mapping_lfb_vram_mapped, start=0x000A, len=0x8000 BUG: kvm_dirty_pages_log_change: invalid parameters 000a-000a7fff Why does this happen? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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
