From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDUjG-0005K2-Gx for qemu-devel@nongnu.org; Fri, 10 Jul 2015 05:36:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDUjD-00055I-1k for qemu-devel@nongnu.org; Fri, 10 Jul 2015 05:36:22 -0400 Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:36261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDUjC-00054j-P0 for qemu-devel@nongnu.org; Fri, 10 Jul 2015 05:36:18 -0400 Received: by widjy10 with SMTP id jy10so10446540wid.1 for ; Fri, 10 Jul 2015 02:36:16 -0700 (PDT) Sender: Paolo Bonzini References: <1436429849-18052-1-git-send-email-rth@twiddle.net> <1436429849-18052-15-git-send-email-rth@twiddle.net> <559E73E6.6000100@redhat.com> <559F7311.1080003@twiddle.net> From: Paolo Bonzini Message-ID: <559F920C.5040108@redhat.com> Date: Fri, 10 Jul 2015 11:36:12 +0200 MIME-Version: 1.0 In-Reply-To: <559F7311.1080003@twiddle.net> Content-Type: text/plain; charset=windows-1252 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: Richard Henderson , qemu-devel@nongnu.org Cc: ehabkost@redhat.com On 10/07/2015 09:24, Richard Henderson wrote: > 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? Yes, for about 8 years. :) > 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. That's a bug. I was somehow convinced that XSAVEOPT never optimized the FP and SSE state, but that's nonsense. Paolo