Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

Hi, 

At 15:08 +0100 on 25 Jul (1311606523), Tim Deegan wrote:
> FWIW, I can reproduce this with a Debian 2.6.32-5-686 n1 guest on
> current unstable tip.  Running two copies of 'kvm' inside that
> (i.e. simple n2s without any disks) I see this on the n0 console:
> 
> (XEN) vvmx.c:1181:d1 vmclear gpa 3661d000 not the same as current vmcs 
> 0000000036459000
> (XEN) vvmx.c:1181:d1 vmclear gpa 36459000 not the same as current vmcs 
> 000000003661d000
> 
> and the n1 guest locks up using 100% cpu on one of its vcpus. 

AFAICS when KVM has two VMs sharing a CPU, it just switches between them
with VMPTRLD, rather than VMCLEARing the current one on every context
switch.  When it migrates one of them away, it VMCLEARs it, even if it's
not the most recently loaded VMCS.

Xen's emulation of VMCLEAR doesn't clear the 'launched' bit in this
case, though the SDM says it should.  The attached patch fixes the hang
for me, but has had only very light testing (i.e. I haven't checked that
proper OSes running inside the KVM VMs behave correctly).

Eddie, does this look right to you?

Jeroen, can you try it and see if it fixes your problems?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Attachment: vmclear
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel