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

[Jeroen Groenewegen van der Weyden <groen692@grosc.com>]

Hi Tim,

I think the behaviour is still the same,

1) cs23726
2) vvmc.c patched with attachment.
3) new compile

after a little while the domu becomes ir-responsive.

with xm dmesg I see a lot of these:
(XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current vmcs 
00000001f448f000
(XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current vmcs 
00000001f448f000


Note: I have to say, patching this on this level is not common practice 
for me. although I think I did it the right way. please keep in mind I 
can make mistakes on this level.

mfg,
Jeroen.

Op 25-7-2011 18:16, Tim Deegan schreef:
> 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.
>