From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDSg6-000612-NK for qemu-devel@nongnu.org; Fri, 10 Jul 2015 03:24:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDSg1-0008C9-Mp for qemu-devel@nongnu.org; Fri, 10 Jul 2015 03:24:58 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:36126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDSg1-0008C3-GB for qemu-devel@nongnu.org; Fri, 10 Jul 2015 03:24:53 -0400 Received: by wgxm20 with SMTP id m20so58463091wgx.3 for ; Fri, 10 Jul 2015 00:24:08 -0700 (PDT) Sender: Richard Henderson References: <1436429849-18052-1-git-send-email-rth@twiddle.net> <1436429849-18052-15-git-send-email-rth@twiddle.net> <559E73E6.6000100@redhat.com> From: Richard Henderson Message-ID: <559F7311.1080003@twiddle.net> Date: Fri, 10 Jul 2015 08:24:01 +0100 MIME-Version: 1.0 In-Reply-To: <559E73E6.6000100@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/14] target-i386: Enable XCR0 features for user-mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: ehabkost@redhat.com 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. r~