[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 14/14] target-i386: Enable XCR0 features for use

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 14/14] target-i386: Enable XCR0 features for user-mode
Date: Fri, 10 Jul 2015 08:24:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

On 07/09/2015 02:15 PM, Paolo Bonzini wrote:
On 09/07/2015 10:17, Richard Henderson wrote:
+    /* ??? This variable is somewhat silly.  Methinks KVM should be
+       using XCR0 to store into the XSTATE_BV field.  Either that or
+       there's more missing information, e.g. the AVX bits.  */
+    env->xstate_bv = XSTATE_FP;
+    if (env->features[FEAT_1_EDX] & CPUID_SSE) {
+        env->xstate_bv |= XSTATE_SSE;
+    }
+    if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_MPX) {
+        env->xstate_bv |= XSTATE_BNDREGS | XSTATE_BNDCSR;
+    }

xstate_bv != xcr0 if the kernel is using XSAVEOPT and some of the values
were in the initial state.  Legacy state is never optimized, hence the
value of env->xstate_bv after reset.  So I think this hunk is wrong,
while the other is correct.

Yes, it's a copy of the field of the same name from the xsave format.

Have we stopped using tcg entirely when kvm is enabled? I guess so, since I seem to recall an effort to build qemu without tcg support. So any fears about tcg corrupting kvm state would be unfounded, right?

If so, I can see how this variable aids initial xsave construction as well as copying the xsave block during migration.

It does beg the question of why xstate_bv isn't zero at reset. Surely all of the xmm and fpu registers are in INIT state at this time, and that's what the XRSTOR that will consume this block is going to care about.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]