* [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI
@ 2015-09-30 22:33 Bill Paul
2015-10-01 8:28 ` Paolo Bonzini
2015-10-02 16:21 ` Eduardo Habkost
0 siblings, 2 replies; 3+ messages in thread
From: Bill Paul @ 2015-09-30 22:33 UTC (permalink / raw)
To: qemu-devel; +Cc: Paolo Bonzini, Eduardo Habkost, Richard Henderson
When doing a re-initialization of a CPU core, the default state is to _not_
have 64-bit long mode enabled. This means the LME (long mode enable) and LMA
(long mode active) bits in the EFER model-specific register should be cleared.
However, the EFER state is part of the CPU environment which is
preserved by do_cpu_init(), so if EFER.LME and EFER.LMA were set at the
time an INIT IPI was received, they will remain set after the init completes.
This is contrary to what the Intel architecture manual describes and what
happens on real hardware, and it leaves the CPU in a weird state that the
guest can't clear.
To fix this, the 'efer' member of the CPUX86State structure has been moved
to an area outside the region preserved by do_cpu_init(), so that it can
be properly re-initialized by x86_cpu_reset().
Signed-off-by: Bill Paul <wpaul@windriver.com>
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Eduardo Habkost <ehabkost@redhat.com>
---
target-i386/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 034fab6..fac773c 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -833,6 +833,7 @@ typedef struct CPUX86State {
BNDReg bnd_regs[4];
BNDCSReg bndcs_regs;
uint64_t msr_bndcfgs;
+ uint64_t efer;
/* Beginning of state preserved by INIT (dummy marker). */
struct {} start_init_save;
@@ -865,7 +866,6 @@ typedef struct CPUX86State {
uint32_t sysenter_cs;
target_ulong sysenter_esp;
target_ulong sysenter_eip;
- uint64_t efer;
uint64_t star;
uint64_t vm_hsave;
--
1.8.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI
2015-09-30 22:33 [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI Bill Paul
@ 2015-10-01 8:28 ` Paolo Bonzini
2015-10-02 16:21 ` Eduardo Habkost
1 sibling, 0 replies; 3+ messages in thread
From: Paolo Bonzini @ 2015-10-01 8:28 UTC (permalink / raw)
To: Bill Paul, qemu-devel; +Cc: Eduardo Habkost, Richard Henderson
On 01/10/2015 00:33, Bill Paul wrote:
> When doing a re-initialization of a CPU core, the default state is to _not_
> have 64-bit long mode enabled. This means the LME (long mode enable) and LMA
> (long mode active) bits in the EFER model-specific register should be cleared.
>
> However, the EFER state is part of the CPU environment which is
> preserved by do_cpu_init(), so if EFER.LME and EFER.LMA were set at the
> time an INIT IPI was received, they will remain set after the init completes.
>
> This is contrary to what the Intel architecture manual describes and what
> happens on real hardware, and it leaves the CPU in a weird state that the
> guest can't clear.
>
> To fix this, the 'efer' member of the CPUX86State structure has been moved
> to an area outside the region preserved by do_cpu_init(), so that it can
> be properly re-initialized by x86_cpu_reset().
>
> Signed-off-by: Bill Paul <wpaul@windriver.com>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Richard Henderson <rth@twiddle.net>
> CC: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> target-i386/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 034fab6..fac773c 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -833,6 +833,7 @@ typedef struct CPUX86State {
> BNDReg bnd_regs[4];
> BNDCSReg bndcs_regs;
> uint64_t msr_bndcfgs;
> + uint64_t efer;
>
> /* Beginning of state preserved by INIT (dummy marker). */
> struct {} start_init_save;
> @@ -865,7 +866,6 @@ typedef struct CPUX86State {
> uint32_t sysenter_cs;
> target_ulong sysenter_esp;
> target_ulong sysenter_eip;
> - uint64_t efer;
> uint64_t star;
>
> uint64_t vm_hsave;
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI
2015-09-30 22:33 [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI Bill Paul
2015-10-01 8:28 ` Paolo Bonzini
@ 2015-10-02 16:21 ` Eduardo Habkost
1 sibling, 0 replies; 3+ messages in thread
From: Eduardo Habkost @ 2015-10-02 16:21 UTC (permalink / raw)
To: Bill Paul; +Cc: Paolo Bonzini, qemu-devel, Richard Henderson
On Wed, Sep 30, 2015 at 03:33:29PM -0700, Bill Paul wrote:
> When doing a re-initialization of a CPU core, the default state is to _not_
> have 64-bit long mode enabled. This means the LME (long mode enable) and LMA
> (long mode active) bits in the EFER model-specific register should be cleared.
>
> However, the EFER state is part of the CPU environment which is
> preserved by do_cpu_init(), so if EFER.LME and EFER.LMA were set at the
> time an INIT IPI was received, they will remain set after the init completes.
>
> This is contrary to what the Intel architecture manual describes and what
> happens on real hardware, and it leaves the CPU in a weird state that the
> guest can't clear.
>
> To fix this, the 'efer' member of the CPUX86State structure has been moved
> to an area outside the region preserved by do_cpu_init(), so that it can
> be properly re-initialized by x86_cpu_reset().
>
> Signed-off-by: Bill Paul <wpaul@windriver.com>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Richard Henderson <rth@twiddle.net>
> CC: Eduardo Habkost <ehabkost@redhat.com>
Applied to x86 tree. Thanks!
--
Eduardo
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-10-02 16:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-30 22:33 [Qemu-devel] [PATCH] Correctly re-init EFER state during INIT IPI Bill Paul
2015-10-01 8:28 ` Paolo Bonzini
2015-10-02 16:21 ` Eduardo Habkost
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).