From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Error booting Xen Date: Tue, 26 Jan 2016 06:22:16 -0700 Message-ID: <56A7811802000078000CB144@prv-mh.provo.novell.com> References: <569D2A49.1090409@citrix.com> <1453141749.11427.92.camel@citrix.com> <569E4A0102000078000C8917@prv-mh.provo.novell.com> <1453215095.11427.144.camel@citrix.com> <569E5118.4030704@citrix.com> <569E76B102000078000C8C14@prv-mh.provo.novell.com> <569E6C36.3070402@citrix.com> <1453223282.11427.149.camel@citrix.com> <569F6A2102000078000C8F20@prv-mh.provo.novell.com> <1453389242.3116.106.camel@citrix.com> <56A6344C02000078000CAA56@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Harmandeep Kaur Cc: Andrew Cooper , Dario Faggioli , xen-devel@lists.xen.org, Shuai Ruan List-Id: xen-devel@lists.xenproject.org >>> On 26.01.16 at 13:51, wrote: > I tried the patch and I am very happy to inform you > all that the patch has solved my problem. Now I am > able to boot Xen without disabling XSAVE. I have > full log of boot at http://paste2.org/gVW0Z9nm (if > any one is interested. also "XXX Hello, this is my > first mod :)" is printed by my mod, so ignore that > one). Thanks for trying it out, but while I'm glad it helped I'm afraid we're not done here. With (for every vCPU) (XEN) traps.c:3290: GPF (0000): ffff82d0801c1d08 -> ffff82d080252e5c (XEN) d0v1 fault#1: mxcsr=00001f80 (XEN) d0v1 xs=0000000000000000 xc=0000000000000000 (XEN) d0v1 r0=0000000000000000 r1=0000000000000000 (XEN) d0v1 r2=0000000000000000 r3=0000000000000000 (XEN) d0v1 r4=0000000000000000 r5=0000000000000000 (XEN) traps.c:3290: GPF (0000): ffff82d0801c1d08 -> ffff82d080252e5c (XEN) d0v1 fault#2: mxcsr=00001f80 (XEN) d0v1 xs=0000000000000000 xc=0000000000000000 (XEN) d0v1 r0=0000000000000000 r1=0000000000000000 (XEN) d0v1 r2=0000000000000000 r3=0000000000000000 (XEN) d0v1 r4=0000000000000000 r5=0000000000000000 it continues to be unclear why bit 63 in the value printed as xc= isn't set from the beginning. Or wait, I think I see where the problem is. Here's a 3rd patch, to try together with the other two. The expectation would be for the above log messages to then disappear altogether. (And then the patch should also work on its own, i.e. with the other two removed again.) Please let us know. Thanks, Jan x86/xstate: don't unintentionally clear compaction bit When the VGCF_I387_VALID flag is clear in arch_set_info_guest()'s input we must not clear the compaction bit when using XSAVES/XRSTORS. Split initialization of xcomp_bv from the other FPU/SSE/AVX related state setup in this function. Signed-off-by: Jan Beulich --- unstable.orig/xen/arch/x86/domain.c +++ unstable/xen/arch/x86/domain.c @@ -922,15 +922,10 @@ int arch_set_info_guest( { memcpy(v->arch.fpu_ctxt, &c.nat->fpu_ctxt, sizeof(c.nat->fpu_ctxt)); if ( v->arch.xsave_area ) - { v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE; - v->arch.xsave_area->xsave_hdr.xcomp_bv = - cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0; - } } else if ( v->arch.xsave_area ) - memset(&v->arch.xsave_area->xsave_hdr, 0, - sizeof(v->arch.xsave_area->xsave_hdr)); + v->arch.xsave_area->xsave_hdr.xstate_bv = 0; else { typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt; @@ -939,6 +934,11 @@ int arch_set_info_guest( fpu_sse->fcw = FCW_DEFAULT; fpu_sse->mxcsr = MXCSR_DEFAULT; } + if ( cpu_has_xsaves ) + { + ASSERT(v->arch.xsave_area); + v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_COMPACTION_ENABLED; + } if ( !compat ) {