Re: KVM VMX: register state after reset violates spec
Thus spake Gleb Natapov g...@redhat.com: On Thu, Nov 29, 2012 at 03:07:38PM +0100, Julian Stecklina wrote: Hello, 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. [...] Shouldn't vmx_vcpu_reset actively clear those registers? And from a quick glance at the SVM code the problem might exist there, too. 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: [...] I take it that they are undefined on the first transition to 64-bit mode too. AMD spec says that they should be zeroed on reset, so lets do that. Also SVM does not set EDX to correct value on reset. I'll post a revised patch later today. Julian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM VMX: register state after reset violates spec
Thus spake Gleb Natapov g...@redhat.com: 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: [...] I take it that they are undefined on the first transition to 64-bit mode too. AMD spec says that they should be zeroed on reset, so lets do that. Also SVM does not set EDX to correct value on reset. It should be: I have posted a new version of the patch taking your suggestions into account. The VMX version is working for me. I could not test it on AMD hardware, though. Julian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM VMX: register state after reset violates spec
On Thu, Nov 29, 2012 at 03:07:38PM +0100, Julian Stecklina wrote: Hello, 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. Specifically for our case we see at the end of vmx_vcpu_reset the following vcpu state: regs_avail=ffef regs_dirty=00010010 EIP= EAX=06e8 EBX=0001 ECX=8001 EDX=0600 ESI=d238 EDI= EBP= ESP= although EAX, EBX, ECX, ESI, EDI, EBP, ESP should _all_ be zero. See http://download.intel.com/products/processor/manual/253668.pdf section 9.1.1 (page 9-2). Shouldn't vmx_vcpu_reset actively clear those registers? And from a quick glance at the SVM code the problem might exist there, too. 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 to 64-bit mode. I take it that they are undefined on the first transition to 64-bit mode too. AMD spec says that they should be zeroed on reset, so lets do that. Also SVM does not set EDX to correct value on reset. It should be: Stepping ID (bits 3:0)—This field identifies the processor-revision level. Extended Model (bits 19:16) and Model (bits 7:4)—These fields combine to differentiate processor models within a instruction family. For 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 field, comprising an extended-model portion in bits 19:16 with a legacy portion in bits 7:4 Extended Family (bits 27:20) and Family (bits 11:8)—These fields combine to differentiate processors by their microarchitecture. A workaround is to use qemu-kvm with -kvm-no-irqchip. Julian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM VMX: register state after reset violates spec
Hello, 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. Specifically for our case we see at the end of vmx_vcpu_reset the following vcpu state: regs_avail=ffef regs_dirty=00010010 EIP= EAX=06e8 EBX=0001 ECX=8001 EDX=0600 ESI=d238 EDI= EBP= ESP= although EAX, EBX, ECX, ESI, EDI, EBP, ESP should _all_ be zero. See http://download.intel.com/products/processor/manual/253668.pdf section 9.1.1 (page 9-2). Shouldn't vmx_vcpu_reset actively clear those registers? And from a quick glance at the SVM code the problem might exist there, too. A workaround is to use qemu-kvm with -kvm-no-irqchip. Julian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
