From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: KVM VMX: register state after reset violates spec Date: Sun, 2 Dec 2012 15:38:02 +0200 Message-ID: <20121202133802.GA8731@redhat.com> References: <87y5hkjydx.fsf@os.inf.tu-dresden.de> Mime-Version: 1.0 Content-Type: text/plain; charset=cp1255 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Julian Stecklina Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37257 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752064Ab2LBNiH convert rfc822-to-8bit (ORCPT ); Sun, 2 Dec 2012 08:38:07 -0500 Content-Disposition: inline In-Reply-To: <87y5hkjydx.fsf@os.inf.tu-dresden.de> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 29, 2012 at 03:07:38PM +0100, Julian Stecklina wrote: > Hello, >=20 > we have noticed that at least on 3.6.8 with VMX after a VCPU has been > reset via the INIT-SIPI-SIPI sequence its register state violates > Intel's specification. >=20 > Specifically for our case we see at the end of vmx_vcpu_reset the > following vcpu state: >=20 > regs_avail=3Dffefffff regs_dirty=3D00010010 > EIP=3D00000000 EAX=3D000006e8 EBX=3D00000001 ECX=3D80000001 EDX=3D000= 00600 > ESI=3D0000d238 EDI=3D00000000 EBP=3D00000000 ESP=3D00000000 >=20 > although EAX, EBX, ECX, ESI, EDI, EBP, ESP should _all_ be zero. See > http://download.intel.com/products/processor/manual/253668.pdf sectio= n > 9.1.1 (page 9-2). >=20 > Shouldn't vmx_vcpu_reset actively clear those registers? And from a > quick glance at the SVM code the problem might exist there, too. >=20 It should, so why not move the fix to kvm_vcpu_reset() so it will work for both. Also what about R8-R15? Intel SDM says nothing about them in the section you mention, but in Volume 1 section 3.4.1.1 is says: Registers only available in 64-bit mode (R8-R15 and XMM8-XMM15) are preserved across transitions from 64-bit mode into compatibility mode then back into 64-bit mode. However, values of R8-R15 and XMM8-XMM15 are undefined after transitions from 64-bit mode through compatibility mode to legacy or real mode and then back through compatibility mode t= o 64-bit mode. I take it that they are undefined on the first transition to 64-bit mod= e too. AMD spec says that they should be zeroed on reset, so lets do that= =2E Also SVM does not set EDX to correct value on reset. It should be: Stepping ID (bits 3:0)=97This field identifies the processor-revision = level. Extended Model (bits 19:16) and Model (bits 7:4)=97These fields combin= e to differentiate processor models within a instruction family. = =46or example, two processors may share the same microarchitecture= but differ in their feature set. Such processors are considered = different models within the same instruction family. This is a split f= ield, comprising an extended-model portion in bits 19:16 with a le= gacy portion in bits 7:4 Extended Family (bits 27:20) and Family (bits 11:8)=97These fields com= bine to differentiate processors by their microarchitecture. > A workaround is to use qemu-kvm with -kvm-no-irqchip. >=20 > Julian >=20 > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.