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

[Jeroen Groenewegen van der Weyden <groen692@xxxxxxxxx>]

Tim, This improved a lot. the domu does not become in-responsive anymore. However, all four l2 guest are started. but 2 out of 4 are hanging/in-responsive after 30 to 60 seconds.

L1 domu (sles11sp1)
 -> seems to be ok

L2-1 propetary OS, seems to be ok
L2-2 propetary OS, seems to be ok
l2-3 sles10sp3, hanging/in-responsive
l2-4 sles10sp3, hanging/in-responsive

no degug/error messages in dmesg.

mfg,
jeroen

Op 26-7-2011 13:42, Tim Deegan schreef:

At 12:46 +0200 on 26 Jul (1311684389), Jeroen Groenewegen van der Weyden wrote:

Here my input

Thanks.  Looks very similar to the bug I thought I fixed with my patch.

VCPUs 1 and 3 are always at 0xa01a1c9d: <0f> 01 c2 eb 03 0f 01 c3
which is probably this fragment of code from KVM's vmx_vcpu_run():

        /* Enter guest mode */
        "jne .Llaunched \n\t"
	__ex(ASM_VMX_VMLAUNCH) "\n\t"
        "jmp .Lkvm_vmx_return \n\t"
        ".Llaunched: " __ex(ASM_VMX_VMRESUME) "\n\t"
	".Lkvm_vmx_return: "

So, just like the case I saw, they're trying to VMLAUNCH a VMCS and
failing.  That should only fail if the VMCS is already launched. 

I think the reason they're _stuck_ is that error paths for VMLAUNCH and
VMRESUME emulation are wrong; I can fix them up a little but I suspect
that won't solve the problem; just change it from a hang to some other
failure mode.

Can you try the attached patch instead of the previous one? 

Tim.

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

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