From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Groenewegen van der Weyden Subject: Re: [PATCH 20 of 20] n2 MSR handling and capability exposure Date: Tue, 26 Jul 2011 09:15:30 +0200 Message-ID: <4E2E6992.9030407@grosc.com> References: <20110701090145.GS9784@whitby.uk.xensource.com> <4E0D9948.5000508@amd.com> <4E0D9D48.20308@grosc.com> <20110704085810.GZ17634@whitby.uk.xensource.com> <4E16ADD9.4060304@grosc.com> <1A42CE6F5F474C41B63392A5F80372B212DAB9DD82@shsmsx501.ccr.corp.intel.com> <4E258DC4.4050106@grosc.com> <1A42CE6F5F474C41B63392A5F80372B212DAC025EB@shsmsx501.ccr.corp.intel.com> <4E26E23D.4030000@grosc.com> <20110725140843.GC8970@whitby.uk.xensource.com> <20110725161657.GF8970@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110725161657.GF8970@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "Christoph.Egger@amd.com" , "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org 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. >