WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
From: Jeroen Groenewegen van der Weyden <groen692@xxxxxxxxx>
Date: Tue, 26 Jul 2011 09:15:30 +0200
Cc: "Christoph.Egger@xxxxxxx" <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Tue, 26 Jul 2011 00:16:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110725161657.GF8970@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110701090145.GS9784@xxxxxxxxxxxxxxxxxxxxxxx> <4E0D9948.5000508@xxxxxxx> <4E0D9D48.20308@xxxxxxxxx> <20110704085810.GZ17634@xxxxxxxxxxxxxxxxxxxxxxx> <4E16ADD9.4060304@xxxxxxxxx> <1A42CE6F5F474C41B63392A5F80372B212DAB9DD82@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E258DC4.4050106@xxxxxxxxx> <1A42CE6F5F474C41B63392A5F80372B212DAC025EB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E26E23D.4030000@xxxxxxxxx> <20110725140843.GC8970@xxxxxxxxxxxxxxxxxxxxxxx> <20110725161657.GF8970@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
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.



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

<Prev in Thread] Current Thread [Next in Thread>