Re: KVM, Entropy and Windows

[Avi Kivity]

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

[Avi Kivity]

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

[Avi Kivity]

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 Kivity
>  >>   ---
>  >>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?

[Avi Kivity]

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

[Vadim Rozenfeld]

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?

[Nadav Har'El]

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

[Dor Laor]

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?

[Avi Kivity]

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

[Philipp Hahn]

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

[Vadim Rozenfeld]

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

[Stefan Hajnoczi]

On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn  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

[Gleb Natapov]

On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote:
> On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn  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 o

Re: [Qemu-devel] KVM call minutes for Feb 15

[Anthony Liguori]

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

[Avi Kivity]

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

[Avi Kivity]

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

[Avi Kivity]

Signed-off-by: Avi Kivity 
---
 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

[Avi Kivity]

Signed-off-by: Avi Kivity 
---
 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 read(self):
-   

[PATCH 3/4] kvm_stat: allow enabling/disabling events dynamicalls

[Avi Kivity]

Signed-off-by: Avi Kivity 
---
 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

[Amit Shah]

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"

[Avi Kivity]

Pressing 'x' enables drilldown into kvm_exit reasons.  Pressing it
again reverts to normal behaviour.

Signed-off-by: Avi Kivity 
---
 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

[Vadim Rozenfeld]

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  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)

Re: [Qemu-devel] KVM call minutes for Feb 15

[Anthony Liguori]

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

[Avi Kivity]

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

[Anthony Liguori]

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

[Anthony Liguori]

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

[Peter Maydell]

On 17 February 2011 13:37, Anthony Liguori  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

[Anthony Liguori]

On 02/17/2011 07:59 AM, Peter Maydell wrote:

On 17 February 2011 13:37, Anthony Liguori  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

[Avi Kivity]

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

[Stefan Hajnoczi]

On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld  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  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

[PATCH] qemu-kvm: Remove merge artifact

[Jan Kiszka]

Signed-off-by: Jan Kiszka 
---
 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

[Vadim Rozenfeld]

On Thu, 2011-02-17 at 14:26 +, Stefan Hajnoczi wrote:
> On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld  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  
> >> > 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 VirtI

Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2

[Philipp Hahn]

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 


> 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

[Vadim Rozenfeld]

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 
> 
> 
> > 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

[Marcelo Tosatti]

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

[Marcelo Tosatti]

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 
> CC: Huang Ying 
> CC: Hidetoshi Seto 
> CC: Jin Dongming 
> ---
>  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 

Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback

[Jan Kiszka]

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 
>> CC: Huang Ying 
>> CC: Hidetoshi Seto 
>> CC: Jin Dongming 
>> ---
>>  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->inter

[KVM-AUTOTEST PATCH 2/4] KVM test: kvm_config.py: allow 'include' when parsing strings

[Michael Goldish]

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 
---
 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

[Michael Goldish]

Signed-off-by: Michael Goldish 
---
 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()

[Michael Goldish]

Signed-off-by: Michael Goldish 
---
 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

[Michael Goldish]

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 
---
 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] ")
+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

[Marcelo Tosatti]

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 
> >> CC: Huang Ying 
> >> CC: Hidetoshi Seto 
> >> CC: Jin Dongming 
> >> ---
> >>  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 pic

Re: [PATCH 08/13] kvm: x86: Inject pending MCE events on state writeback

[Jan Kiszka]

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

[Marcelo Tosatti]

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 
> CC: Huang Ying 
> CC: Hidetoshi Seto 
> CC: Jin Dongming 

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

[Jan Kiszka]

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 
>> CC: Huang Ying 
>> CC: Hidetoshi Seto 
>> CC: Jin Dongming 
> 
> 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

[Marcelo Tosatti]

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

[Anthony Liguori]

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)

[Da Powah]

> > 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

[Jan Kiszka]

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 
> CC: Alexander Graf 
> ---
>  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 

Commit 7a39fe5882 failed to convert the right arch function.

Signed-off-by: Jan Kiszka 
---
 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)

[Da Powah]

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
 000

[Bug 29232] [VT-d] VT-d device passthrough fail to guest

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=29232


Rafael J. Wysocki  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

[qemu-kvm]

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

[qemu-kvm]

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

[qemu-kvm]

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

[qemu-kvm]

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

[Gerhard Wiesinger]

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