From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH 20 of 20] n2 MSR handling and capability exposure Date: Mon, 25 Jul 2011 17:16:57 +0100 Message-ID: <20110725161657.GF8970@whitby.uk.xensource.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Return-path: Content-Disposition: inline In-Reply-To: <20110725140843.GC8970@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: Jeroen Groenewegen van der Weyden Cc: "Christoph.Egger@amd.com" , "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline 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 Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="vmclear" Nested VMX: always mark VVMCS as not-launched on VMCLEAR. The SDM says to flush changes and clear the launch state even if this isn't the "current VMCS", and KVM seems to rely on this behaviour. Signed-off-by: Tim Deegan diff -r 9dbbf1631193 xen/arch/x86/hvm/vmx/vvmx.c --- a/xen/arch/x86/hvm/vmx/vvmx.c Mon Jul 25 14:21:13 2011 +0100 +++ b/xen/arch/x86/hvm/vmx/vvmx.c Mon Jul 25 17:16:01 2011 +0100 @@ -1162,6 +1162,7 @@ int nvmx_handle_vmclear(struct cpu_user_ struct vmx_inst_decoded decode; struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v); unsigned long gpa = 0; + void *vvmcs; int rc; rc = decode_vmx_inst(regs, &decode, &gpa, 0); @@ -1179,6 +1180,13 @@ int nvmx_handle_vmclear(struct cpu_user_ gdprintk(XENLOG_WARNING, "vmclear gpa %lx not the same as current vmcs %"PRIpaddr"\n", gpa, nvcpu->nv_vvmcxaddr); + + /* Even if this VMCS isn't the current one, we must clear it. */ + vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT); + if ( vvmcs ) + __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0); + hvm_unmap_guest_frame(vvmcs); + vmreturn(regs, VMSUCCEED); goto out; } --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --xHFwDpU9dbj6ez1V--