diff mbox

Error booting Xen

Message ID 56A8E20C02000078000CB944@prv-mh.provo.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich Jan. 27, 2016, 2:28 p.m. UTC
>>> On 27.01.16 at 14:28, <write.harmandeep@gmail.com> wrote:
> I tried to apply your patches but it seems
> to have some merge conflicts with latest
> staging branch.
> 
> ~/xen$ git apply ~/Downloads/x86-xsaves-init.patch
> error: patch failed: xen/arch/x86/hvm/hvm.c:2094
> error: xen/arch/x86/hvm/hvm.c: patch does not apply

Oh, indeed. Here's a better set.

Jan
x86/xstate: fix fault behavior on XRSTORS

XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead
of just fixing this issue, overhaul the fault recovery code, which -
one of the many mistakes made when xstate support got introduced - was
blindly mirroring that accompanying FXRSTOR, neglecting the fact that
XRSTOR{,S} aren't all-or-nothing instructions. The new code, first of
all, does all the recovery actions in C, simplifying the inline
assembly used. And it does its work in a multi-stage fashion: Upon
first seeing a fault, state fixups get applied strictly based on what
architecturally may cause #GP. When seeing another fault despite the
fixups done, state gets fully reset. A third fault would then lead to
crashing the domain (instead of hanging the hypervisor in an infinite
loop of recurring faults).

Reported-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
x86/xstate: fix xcomp_bv initialization

We must not clear the compaction bit when using XSAVES/XRSTORS. And
we need to guarantee that xcomp_bv never has any bits clear which
are set in xstate_bv (which requires partly undoing commit 83ae0bb226
["x86/xsave: simplify xcomp_bv initialization"]). Split initialization
of xcomp_bv from the other FPU/SSE/AVX related state setup in
arch_set_info_guest() and hvm_load_cpu_ctxt().

Reported-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- unstable.orig/xen/arch/x86/domain.c	2015-12-18 12:21:58.000000000 +0100
+++ unstable/xen/arch/x86/domain.c	2016-01-27 09:52:37.000000000 +0100
@@ -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,14 @@ 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 |
+            v->arch.xsave_area->xsave_hdr.xstate_bv;
+    }
+    else if ( v->arch.xsave_area )
+        v->arch.xsave_area->xsave_hdr.xcomp_bv = 0;
 
     if ( !compat )
     {
--- unstable.orig/xen/arch/x86/hvm/hvm.c	2015-12-18 12:22:20.000000000 +0100
+++ unstable/xen/arch/x86/hvm/hvm.c	2016-01-27 15:25:13.000000000 +0100
@@ -1974,6 +1974,7 @@ static int hvm_load_cpu_ctxt(struct doma
     struct hvm_hw_cpu ctxt;
     struct segment_register seg;
     const char *errstr;
+    struct xsave_struct *xsave_area;
 
     /* Which vcpu is this? */
     vcpuid = hvm_load_instance(h);
@@ -2100,20 +2101,24 @@ static int hvm_load_cpu_ctxt(struct doma
     seg.attr.bytes = ctxt.ldtr_arbytes;
     hvm_set_segment_register(v, x86_seg_ldtr, &seg);
 
+    /* Cover xsave-absent save file restoration on xsave-capable host. */
+    xsave_area = xsave_enabled(v) ? NULL : v->arch.xsave_area;
+
     v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
     if ( v->fpu_initialised )
     {
         memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
-        /* In case xsave-absent save file is restored on a xsave-capable host */
-        if ( cpu_has_xsave && !xsave_enabled(v) )
-        {
-            struct xsave_struct *xsave_area = v->arch.xsave_area;
-
+        if ( xsave_area )
             xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-            xsave_area->xsave_hdr.xcomp_bv =
-                cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
-        }
     }
+    else if ( xsave_area )
+    {
+        xsave_area->xsave_hdr.xstate_bv = 0;
+        xsave_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
+    }
+    if ( cpu_has_xsaves && xsave_area )
+        xsave_area->xsave_hdr.xcomp_bv = XSTATE_COMPACTION_ENABLED |
+            xsave_area->xsave_hdr.xstate_bv;
 
     v->arch.user_regs.eax = ctxt.rax;
     v->arch.user_regs.ebx = ctxt.rbx;
@@ -5502,8 +5507,8 @@ void hvm_vcpu_reset_state(struct vcpu *v
     if ( v->arch.xsave_area )
     {
         v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP;
-        v->arch.xsave_area->xsave_hdr.xcomp_bv =
-            cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
+        v->arch.xsave_area->xsave_hdr.xcomp_bv = cpu_has_xsaves
+            ? XSTATE_COMPACTION_ENABLED | XSTATE_FP : 0;
     }
 
     v->arch.vgc_flags = VGCF_online;
x86: adjust xsave structure attributes

The packed attribute was pointlessly used here - there are no
misaligned fields, and hence even if the attribute took effect, it
would at best lead to the compiler generating worse code.

At the same time specify the required alignment of the fpu_sse sub-
structure, such that the various typeof() uses on that field obtain
pointers to properly aligned memory (knowledge which a compiler may
want to make use of).

Also add suitable build-time checks.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- unstable.orig/xen/arch/x86/i387.c	2016-01-25 11:30:11.000000000 +0100
+++ unstable/xen/arch/x86/i387.c	2016-01-25 09:35:36.000000000 +0100
@@ -277,7 +277,9 @@ int vcpu_init_fpu(struct vcpu *v)
     }
     else
     {
-        v->arch.fpu_ctxt = _xzalloc(sizeof(v->arch.xsave_area->fpu_sse), 16);
+        BUILD_BUG_ON(__alignof(v->arch.xsave_area->fpu_sse) < 16);
+        v->arch.fpu_ctxt = _xzalloc(sizeof(v->arch.xsave_area->fpu_sse),
+                                    __alignof(v->arch.xsave_area->fpu_sse));
         if ( v->arch.fpu_ctxt )
         {
             typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt;
--- unstable.orig/xen/arch/x86/xstate.c	2016-01-25 11:30:11.000000000 +0100
+++ unstable/xen/arch/x86/xstate.c	2016-01-25 09:35:12.000000000 +0100
@@ -414,7 +414,8 @@ int xstate_alloc_save_area(struct vcpu *
     BUG_ON(xsave_cntxt_size < XSTATE_AREA_MIN_SIZE);
 
     /* XSAVE/XRSTOR requires the save area be 64-byte-boundary aligned. */
-    save_area = _xzalloc(xsave_cntxt_size, 64);
+    BUILD_BUG_ON(__alignof(*save_area) < 64);
+    save_area = _xzalloc(xsave_cntxt_size, __alignof(*save_area));
     if ( save_area == NULL )
         return -ENOMEM;
 
--- unstable.orig/xen/include/asm-x86/xstate.h	2016-01-25 11:30:11.000000000 +0100
+++ unstable/xen/include/asm-x86/xstate.h	2016-01-25 11:33:20.000000000 +0100
@@ -48,9 +48,9 @@ extern u64 xfeature_mask;
 extern unsigned int *xstate_sizes;
 
 /* extended state save area */
-struct __packed __attribute__((aligned (64))) xsave_struct
+struct __attribute__((aligned (64))) xsave_struct
 {
-    union {                                  /* FPU/MMX, SSE */
+    union __attribute__((aligned(16))) {     /* FPU/MMX, SSE */
         char x[512];
         struct {
             uint16_t fcw;
x86/xstate: extend validation to cover full header

Since we never hand out compacted state, at least for now we're also
not going to accept such.

Reported-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- unstable.orig/xen/arch/x86/domctl.c	2016-01-27 14:56:10.000000000 +0100
+++ unstable/xen/arch/x86/domctl.c	2016-01-27 10:44:52.000000000 +0100
@@ -958,7 +958,7 @@ long arch_do_domctl(
             {
                 if ( evc->size >= 2 * sizeof(uint64_t) + XSTATE_AREA_MIN_SIZE )
                     ret = validate_xstate(_xcr0, _xcr0_accum,
-                                          _xsave_area->xsave_hdr.xstate_bv);
+                                          &_xsave_area->xsave_hdr);
             }
             else if ( !_xcr0 )
                 ret = 0;
--- unstable.orig/xen/arch/x86/hvm/hvm.c	2016-01-27 15:25:13.000000000 +0100
+++ unstable/xen/arch/x86/hvm/hvm.c	2016-01-27 15:26:15.000000000 +0100
@@ -2191,6 +2191,19 @@ static int hvm_save_cpu_xsave_states(str
     return 0;
 }
 
+/*
+ * Structure layout conformity checks, documenting correctness of the cast in
+ * the invocation of validate_xstate() below.
+ * Leverage CONFIG_COMPAT machinery to perform this.
+ */
+#define xen_xsave_hdr xsave_hdr
+#define compat_xsave_hdr hvm_hw_cpu_xsave_hdr
+CHECK_FIELD_(struct, xsave_hdr, xstate_bv);
+CHECK_FIELD_(struct, xsave_hdr, xcomp_bv);
+CHECK_FIELD_(struct, xsave_hdr, reserved);
+#undef compat_xsave_hdr
+#undef xen_xsave_hdr
+
 static int hvm_load_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
 {
     unsigned int vcpuid, size;
@@ -2246,7 +2259,7 @@ static int hvm_load_cpu_xsave_states(str
     h->cur += desc->length;
 
     err = validate_xstate(ctxt->xcr0, ctxt->xcr0_accum,
-                          ctxt->save_area.xsave_hdr.xstate_bv);
+                          (const void *)&ctxt->save_area.xsave_hdr);
     if ( err )
     {
         printk(XENLOG_G_WARNING
--- unstable.orig/xen/arch/x86/xstate.c	2016-01-27 10:23:06.000000000 +0100
+++ unstable/xen/arch/x86/xstate.c	2016-01-27 10:48:22.000000000 +0100
@@ -614,17 +614,24 @@ static bool_t valid_xcr0(u64 xcr0)
     return !(xcr0 & XSTATE_BNDREGS) == !(xcr0 & XSTATE_BNDCSR);
 }
 
-int validate_xstate(u64 xcr0, u64 xcr0_accum, u64 xstate_bv)
+int validate_xstate(u64 xcr0, u64 xcr0_accum, const struct xsave_hdr *hdr)
 {
-    if ( (xstate_bv & ~xcr0_accum) ||
+    unsigned int i;
+
+    if ( (hdr->xstate_bv & ~xcr0_accum) ||
          (xcr0 & ~xcr0_accum) ||
          !valid_xcr0(xcr0) ||
          !valid_xcr0(xcr0_accum) )
         return -EINVAL;
 
-    if ( xcr0_accum & ~xfeature_mask )
+    if ( (xcr0_accum & ~xfeature_mask) ||
+         hdr->xcomp_bv )
         return -EOPNOTSUPP;
 
+    for ( i = 0; i < ARRAY_SIZE(hdr->reserved); ++i )
+        if ( hdr->reserved[i] )
+            return -EIO;
+
     return 0;
 }
 
--- unstable.orig/xen/include/asm-x86/xstate.h	2016-01-25 11:33:20.000000000 +0100
+++ unstable/xen/include/asm-x86/xstate.h	2016-01-27 10:57:54.000000000 +0100
@@ -72,14 +72,13 @@ struct __attribute__((aligned (64))) xsa
         };
     } fpu_sse;
 
-    struct {
+    struct xsave_hdr {
         u64 xstate_bv;
         u64 xcomp_bv;
         u64 reserved[6];
     } xsave_hdr;                             /* The 64-byte header */
 
-    struct { char x[XSTATE_YMM_SIZE]; } ymm; /* YMM */
-    char   data[];                           /* Future new states */
+    char data[];                             /* Variable layout states */
 };
 
 /* extended state operations */
@@ -90,7 +89,8 @@ uint64_t get_msr_xss(void);
 void xsave(struct vcpu *v, uint64_t mask);
 void xrstor(struct vcpu *v, uint64_t mask);
 bool_t xsave_enabled(const struct vcpu *v);
-int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum, u64 xstate_bv);
+int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum,
+                                 const struct xsave_hdr *);
 int __must_check handle_xsetbv(u32 index, u64 new_bv);
 void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size);
 void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size);
--- unstable.orig/xen/include/public/arch-x86/hvm/save.h	2016-01-27 14:58:51.000000000 +0100
+++ unstable/xen/include/public/arch-x86/hvm/save.h	2016-01-27 15:26:25.000000000 +0100
@@ -564,12 +564,11 @@ struct hvm_hw_cpu_xsave {
     struct {
         struct { char x[512]; } fpu_sse;
 
-        struct {
+        struct hvm_hw_cpu_xsave_hdr {
             uint64_t xstate_bv;         /* Updated by XRSTOR */
-            uint64_t reserved[7];
+            uint64_t xcomp_bv;          /* Updated by XRSTOR{C,S} */
+            uint64_t reserved[6];
         } xsave_hdr;                    /* The 64-byte header */
-
-        struct { char x[0]; } ymm;    /* YMM */
     } save_area;
 };

Comments

Harmandeep Kaur Jan. 28, 2016, 7:17 p.m. UTC | #1
Latest set looks good. No boot issues. No resets.
Full log at http://paste2.org/NxHNW4vn

Sorry I don't know much about source of last few
lines. I was just tracing in xen when these came.
I was unable to create them again. I will inform
you if I get these again.
Regards,
Harmandeep

On Wed, Jan 27, 2016 at 7:58 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 27.01.16 at 14:28, <write.harmandeep@gmail.com> wrote:
>> I tried to apply your patches but it seems
>> to have some merge conflicts with latest
>> staging branch.
>>
>> ~/xen$ git apply ~/Downloads/x86-xsaves-init.patch
>> error: patch failed: xen/arch/x86/hvm/hvm.c:2094
>> error: xen/arch/x86/hvm/hvm.c: patch does not apply
>
> Oh, indeed. Here's a better set.
>
> Jan
>
Jan Beulich Jan. 29, 2016, 10:13 a.m. UTC | #2
>>> On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote:
> Latest set looks good. No boot issues. No resets.
> Full log at http://paste2.org/NxHNW4vn 

Thanks!

> Sorry I don't know much about source of last few
> lines. I was just tracing in xen when these came.
> I was unable to create them again. I will inform
> you if I get these again.

The WRMSR ones are of no concern. What I'm curious about are the
five instances of

(XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15

Could you check what these addresses correspond to in source?

Also did you meanwhile clarify for yourself what domain(s) are
being started here? So far you've said you don't start any, but
the logs clearly show otherwise. Are there perhaps any that
get auto-started? In which case I'd be interested in you
confirming that these come up fine.

Jan
Dario Faggioli Feb. 3, 2016, 8:23 a.m. UTC | #3
Hey Harmandeep,

On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote:
> > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote:
> > Latest set looks good. No boot issues. No resets.
> > Full log at http://paste2.org/NxHNW4vn 

> > Sorry I don't know much about source of last few
> > lines. I was just tracing in xen when these came.
> > I was unable to create them again. I will inform
> > you if I get these again.
> 
> The WRMSR ones are of no concern. What I'm curious about are the
> five instances of
> 
> (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15
> 
> Could you check what these addresses correspond to in source?
> 
I guess you just happened to forgot to follow up on this question from
Jan?

> So far you've said you don't start any, but
> the logs clearly show otherwise. Are there perhaps any that
> get auto-started? In which case I'd be interested in you
> confirming that these come up fine.
> 
And this too?

Can you please do that? :-)

Regards,
Dario
Harmandeep Kaur Feb. 3, 2016, 11:35 a.m. UTC | #4
On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> Hey Harmandeep,
>
> On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote:
>> > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote:
>> > Latest set looks good. No boot issues. No resets.
>> > Full log at http://paste2.org/NxHNW4vn
>>
>> > Sorry I don't know much about source of last few
>> > lines. I was just tracing in xen when these came.
>> > I was unable to create them again. I will inform
>> > you if I get these again.
>>
>> The WRMSR ones are of no concern. What I'm curious about are the
>> five instances of
>>
>> (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15
>>
>> Could you check what these addresses correspond to in source?
>>
> I guess you just happened to forgot to follow up on this question from
> Jan?

Sorry for responding so late.

$ addr2line -e xen-syms ffff82d08019cb87
xen/xen/arch/x86/traps.c:2820

>> So far you've said you don't start any, but
>> the logs clearly show otherwise. Are there perhaps any that
>> get auto-started? In which case I'd be interested in you
>> confirming that these come up fine.
>>

Maybe I failed to shutdown a guest which was showing up
on next boot. But there are no auto-starting guests.
Following link goes to latest serial log
http://paste2.org/5PDz9bP1 and then I created a guest with
config (http://paste2.org/azvj25Hg) and
http://paste2.org/cgKna0j1 log was presented at terminal.

I hope this helps.

Thanks and regards,
Harmandeep Kaur

> And this too?
>
> Can you please do that? :-)
>
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
Jan Beulich Feb. 3, 2016, 12:49 p.m. UTC | #5
>>> On 03.02.16 at 12:35, <write.harmandeep@gmail.com> wrote:
> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
>> Hey Harmandeep,
>>
>> On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote:
>>> > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote:
>>> > Latest set looks good. No boot issues. No resets.
>>> > Full log at http://paste2.org/NxHNW4vn 
>>>
>>> > Sorry I don't know much about source of last few
>>> > lines. I was just tracing in xen when these came.
>>> > I was unable to create them again. I will inform
>>> > you if I get these again.
>>>
>>> The WRMSR ones are of no concern. What I'm curious about are the
>>> five instances of
>>>
>>> (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15
>>>
>>> Could you check what these addresses correspond to in source?
>>>
>> I guess you just happened to forgot to follow up on this question from
>> Jan?
> 
> Sorry for responding so late.

Thanks for getting back.

> $ addr2line -e xen-syms ffff82d08019cb87
> xen/xen/arch/x86/traps.c:2820

That's the RDMSR one, so (luckily) not of interest here.

>>> So far you've said you don't start any, but
>>> the logs clearly show otherwise. Are there perhaps any that
>>> get auto-started? In which case I'd be interested in you
>>> confirming that these come up fine.
>>>
> 
> Maybe I failed to shutdown a guest which was showing up
> on next boot. But there are no auto-starting guests.
> Following link goes to latest serial log
> http://paste2.org/5PDz9bP1 and then I created a guest with

But this _again_ shows the presence of a (running) Dom1, ...

> config (http://paste2.org/azvj25Hg) and
> http://paste2.org/cgKna0j1 log was presented at terminal.

... and you leave us guessing whether the first of these logs was
indeed captured before you started the guest (as one may imply
from your wording) or after (as one may imply from your claim of
there not being any auto-started guests). Please try to be more
precise in your statements.

Jan
Dario Faggioli Feb. 3, 2016, 12:55 p.m. UTC | #6
On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote:
> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> Maybe I failed to shutdown a guest which was showing up
> on next boot. But there are no auto-starting guests.
> Following link goes to latest serial log
> http://paste2.org/5PDz9bP1 
>
No, sorry, I probably am not getting. Are you saying that, just booting
Xen and *not* doing anything else --either from SSH, from the keyboard
of that box, from serial connection... anything at all-- and without
any guest configured to auto start itself, results in these lines to
appear on your serial console?

tbox login: (d1) mapping kernel into physical memory
(d1) about to get started...
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
(XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
(XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.

Because this is what you just said above, and that's... well... just
impossible?!?! :-O

What's the output then, if you login (either via serial, ssh or regular
keyboad+monitor) and run `xl list' and `xl vcpu-list' as the very first
thing?  What's inside `ls -l /var/log/xen/' (or `ls -l
/var/local/log/xen')?

> and then I created a guest with
> config (http://paste2.org/azvj25Hg) and
> http://paste2.org/cgKna0j1 log was presented at terminal.
> 
Well, it looks like the guest boot did not indeed go well, but that is
probably because of other thing... can you try uncommenting the line
'extra = "root=/dev/xvda1"' from the config?

Regards,
Dario
Andrew Cooper Feb. 3, 2016, 1:10 p.m. UTC | #7
On 03/02/16 12:55, Dario Faggioli wrote:
> On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote:
>> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>  
>> Maybe I failed to shutdown a guest which was showing up
>> on next boot. But there are no auto-starting guests.
>> Following link goes to latest serial log
>> http://paste2.org/5PDz9bP1 
>>
> No, sorry, I probably am not getting. Are you saying that, just booting
> Xen and *not* doing anything else --either from SSH, from the keyboard
> of that box, from serial connection... anything at all-- and without
> any guest configured to auto start itself, results in these lines to
> appear on your serial console?
>
> tbox login: (d1) mapping kernel into physical memory
> (d1) about to get started...
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
>
> Because this is what you just said above, and that's... well... just
> impossible?!?! :-O

This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it
shouldn't.  There is a fix upstream, but this specifically is harmless
noise.

~Andrew
Dario Faggioli Feb. 3, 2016, 1:17 p.m. UTC | #8
On Wed, 2016-02-03 at 13:10 +0000, Andrew Cooper wrote:
> On 03/02/16 12:55, Dario Faggioli wrote:
> > 
> > tbox login: (d1) mapping kernel into physical memory
> > (d1) about to get started...
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081
> > from 0xe023e00800000000 to 0x0023001000000000.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082
> > from 0xffff82d0bfffe080 to 0xffffffff817ef990.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083
> > from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174
> > from 0x000000000000e008 to 0x0000000000000010.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175
> > from 0xffff83026d40ffc0 to 0x0000000000000000.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176
> > from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084
> > from 0x0000000000074700 to 0x0000000000047700.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081
> > from 0xe023e00800000000 to 0x0023001000000000.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082
> > from 0xffff82d0bffff000 to 0xffffffff817ef990.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083
> > from 0xffff82d0bffff020 to 0xffffffff817f1f60.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174
> > from 0x000000000000e008 to 0x0000000000000010.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175
> > from 0xffff8300866fffc0 to 0x0000000000000000.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176
> > from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084
> > from 0x0000000000074700 to 0x0000000000047700.
> > 
> > Because this is what you just said above, and that's... well...
> > just
> > impossible?!?! :-O
> 
> This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it
> shouldn't.  There is a fix upstream, but this specifically is
> harmless
> noise.
> 
That's ok... What we're arguing is that is happens as a consequence of
a domain being created, not just "by itself, after boot, without
starting any domain" !!!! :-)

Regards,
Dario
Harmandeep Kaur Feb. 3, 2016, 1:40 p.m. UTC | #9
On Wed, Feb 3, 2016 at 6:25 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote:
>> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>> >
>> Maybe I failed to shutdown a guest which was showing up
>> on next boot. But there are no auto-starting guests.
>> Following link goes to latest serial log
>> http://paste2.org/5PDz9bP1
>>
> No, sorry, I probably am not getting. Are you saying that, just booting
> Xen and *not* doing anything else --either from SSH, from the keyboard
> of that box, from serial connection... anything at all-- and without
> any guest configured to auto start itself, results in these lines to
> appear on your serial console?
>
> tbox login: (d1) mapping kernel into physical memory
> (d1) about to get started...
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
>
> Because this is what you just said above, and that's... well... just
> impossible?!?! :-O
>
> What's the output then, if you login (either via serial, ssh or regular
> keyboad+monitor) and run `xl list'

$ sudo xl list
Name                                        ID   Mem VCPUs    State    Time(s)
Domain-0                                     0  4096     4     r-----      37.6

> and `xl vcpu-list' as the very first
> thing?

$ sudo xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s)
Affinity (Hard / Soft)
Domain-0                             0     0    3   r--      13.3  all / all
Domain-0                             0     1    0   -b-       7.0  all / all
Domain-0                             0     2    1   -b-       5.4  all / all
Domain-0                             0     3    2   r--      13.5  all / all


> What's inside `ls -l /var/log/xen/' (or `ls -l
> /var/local/log/xen')?

$ ls -l /var/log/xen/
total 48
-rw-r--r-- 1 root adm  28 Jan 23 00:14 xen-hotplug.log
-rw-r--r-- 1 root adm  91 Feb  3 17:14 xl-ubuntu.pvlinux.log
-rw-r--r-- 1 root adm  91 Jan 29 00:54 xl-ubuntu.pvlinux.log.1
-rw-r--r-- 1 root adm 144 Jan 26 23:50 xl-ubuntu.pvlinux.log.10
-rw-r--r-- 1 root adm  91 Jan 29 00:41 xl-ubuntu.pvlinux.log.2
-rw-r--r-- 1 root adm  91 Jan 29 00:32 xl-ubuntu.pvlinux.log.3
-rw-r--r-- 1 root adm  91 Jan 29 00:24 xl-ubuntu.pvlinux.log.4
-rw-r--r-- 1 root adm  91 Jan 28 22:22 xl-ubuntu.pvlinux.log.5
-rw-r--r-- 1 root adm  62 Jan 27 19:09 xl-ubuntu.pvlinux.log.6
-rw-r--r-- 1 root adm  91 Jan 27 19:07 xl-ubuntu.pvlinux.log.7
-rw-r--r-- 1 root adm 222 Jan 27 18:41 xl-ubuntu.pvlinux.log.8
-rw-r--r-- 1 root adm  62 Jan 27 15:03 xl-ubuntu.pvlinux.log.9

>
>> and then I created a guest with
>> config (http://paste2.org/azvj25Hg) and
>> http://paste2.org/cgKna0j1 log was presented at terminal.
>>
> Well, it looks like the guest boot did not indeed go well, but that is
> probably because of other thing... can you try uncommenting the line
> 'extra = "root=/dev/xvda1"' from the config?

Trying this suggestion.

>
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
Jan Beulich Feb. 3, 2016, 2:18 p.m. UTC | #10
>>> On 03.02.16 at 14:40, <write.harmandeep@gmail.com> wrote:
> $ ls -l /var/log/xen/
> total 48
> -rw-r--r-- 1 root adm  28 Jan 23 00:14 xen-hotplug.log
> -rw-r--r-- 1 root adm  91 Feb  3 17:14 xl-ubuntu.pvlinux.log

This date looks suspiciously new.

Jan
Konrad Rzeszutek Wilk Feb. 3, 2016, 4:57 p.m. UTC | #11
On Wed, Feb 03, 2016 at 02:17:26PM +0100, Dario Faggioli wrote:
> On Wed, 2016-02-03 at 13:10 +0000, Andrew Cooper wrote:
> > On 03/02/16 12:55, Dario Faggioli wrote:
> > > 
> > > tbox login: (d1) mapping kernel into physical memory
> > > (d1) about to get started...
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081
> > > from 0xe023e00800000000 to 0x0023001000000000.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082
> > > from 0xffff82d0bfffe080 to 0xffffffff817ef990.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083
> > > from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174
> > > from 0x000000000000e008 to 0x0000000000000010.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175
> > > from 0xffff83026d40ffc0 to 0x0000000000000000.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176
> > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084
> > > from 0x0000000000074700 to 0x0000000000047700.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081
> > > from 0xe023e00800000000 to 0x0023001000000000.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082
> > > from 0xffff82d0bffff000 to 0xffffffff817ef990.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083
> > > from 0xffff82d0bffff020 to 0xffffffff817f1f60.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174
> > > from 0x000000000000e008 to 0x0000000000000010.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175
> > > from 0xffff8300866fffc0 to 0x0000000000000000.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176
> > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60.
> > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084
> > > from 0x0000000000074700 to 0x0000000000047700.
> > > 
> > > Because this is what you just said above, and that's... well...
> > > just
> > > impossible?!?! :-O
> > 
> > This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it
> > shouldn't.  There is a fix upstream, but this specifically is
> > harmless
> > noise.
> > 
> That's ok... What we're arguing is that is happens as a consequence of
> a domain being created, not just "by itself, after boot, without
> starting any domain" !!!! :-)

It has booted. It says 'about to get started...' which is in the early
code of the Linux pvops.
diff mbox

Patch

--- unstable.orig/xen/arch/x86/xstate.c	2016-01-25 09:35:12.000000000 +0100
+++ unstable/xen/arch/x86/xstate.c	2016-01-27 10:23:06.000000000 +0100
@@ -29,6 +29,8 @@  unsigned int *__read_mostly xstate_sizes
 static unsigned int __read_mostly xstate_features;
 static unsigned int __read_mostly xstate_comp_offsets[sizeof(xfeature_mask)*8];
 
+static uint32_t __read_mostly mxcsr_mask = MXCSR_DEFAULT;
+
 /* Cached xcr0 for fast read */
 static DEFINE_PER_CPU(uint64_t, xcr0);
 
@@ -342,6 +344,7 @@  void xrstor(struct vcpu *v, uint64_t mas
     uint32_t hmask = mask >> 32;
     uint32_t lmask = mask;
     struct xsave_struct *ptr = v->arch.xsave_area;
+    unsigned int faults, prev_faults;
 
     /*
      * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
@@ -361,35 +364,85 @@  void xrstor(struct vcpu *v, uint64_t mas
     /*
      * XRSTOR can fault if passed a corrupted data block. We handle this
      * possibility, which may occur if the block was passed to us by control
-     * tools or through VCPUOP_initialise, by silently clearing the block.
+     * tools or through VCPUOP_initialise, by silently adjusting state.
      */
-    switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
+    for ( prev_faults = faults = 0; ; prev_faults = faults )
     {
+        switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
+        {
 #define XRSTOR(pfx) \
         alternative_io("1: .byte " pfx "0x0f,0xae,0x2f\n" \
+                       "3:\n" \
                        "   .section .fixup,\"ax\"\n" \
-                       "2: mov %[size],%%ecx\n" \
-                       "   xor %[lmask_out],%[lmask_out]\n" \
-                       "   rep stosb\n" \
-                       "   lea %[mem],%[ptr]\n" \
-                       "   mov %[lmask_in],%[lmask_out]\n" \
-                       "   jmp 1b\n" \
+                       "2: inc%z[faults] %[faults]\n" \
+                       "   jmp 3b\n" \
                        "   .previous\n" \
                        _ASM_EXTABLE(1b, 2b), \
                        ".byte " pfx "0x0f,0xc7,0x1f\n", \
                        X86_FEATURE_XSAVES, \
-                       ASM_OUTPUT2([ptr] "+&D" (ptr), [lmask_out] "+&a" (lmask)), \
-                       [mem] "m" (*ptr), [lmask_in] "g" (lmask), \
-                       [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size) \
-                       : "ecx")
-
-    default:
-        XRSTOR("0x48,");
-        break;
-    case 4: case 2:
-        XRSTOR("");
-        break;
+                       ASM_OUTPUT2([mem] "+m" (*ptr), [faults] "+g" (faults)), \
+                       [lmask] "a" (lmask), [hmask] "d" (hmask), \
+                       [ptr] "D" (ptr))
+
+        default:
+            XRSTOR("0x48,");
+            break;
+        case 4: case 2:
+            XRSTOR("");
+            break;
 #undef XRSTOR
+        }
+        if ( likely(faults == prev_faults) )
+            break;
+#ifndef NDEBUG
+        gprintk(XENLOG_WARNING, "fault#%u: mxcsr=%08x\n",
+                faults, ptr->fpu_sse.mxcsr);
+        gprintk(XENLOG_WARNING, "xs=%016lx xc=%016lx\n",
+                ptr->xsave_hdr.xstate_bv, ptr->xsave_hdr.xcomp_bv);
+        gprintk(XENLOG_WARNING, "r0=%016lx r1=%016lx\n",
+                ptr->xsave_hdr.reserved[0], ptr->xsave_hdr.reserved[1]);
+        gprintk(XENLOG_WARNING, "r2=%016lx r3=%016lx\n",
+                ptr->xsave_hdr.reserved[2], ptr->xsave_hdr.reserved[3]);
+        gprintk(XENLOG_WARNING, "r4=%016lx r5=%016lx\n",
+                ptr->xsave_hdr.reserved[4], ptr->xsave_hdr.reserved[5]);
+#endif
+        switch ( faults )
+        {
+        case 1:
+            /* Stage 1: Reset state to be loaded. */
+            ptr->xsave_hdr.xstate_bv &= ~mask;
+            /*
+             * Also try to eliminate fault reasons, even if this shouldn't be
+             * needed here (other code should ensure the sanity of the data).
+             */
+            if ( ((mask & XSTATE_SSE) ||
+                  ((mask & XSTATE_YMM) &&
+                   !(ptr->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED))) )
+                ptr->fpu_sse.mxcsr &= mxcsr_mask;
+            if ( cpu_has_xsaves || cpu_has_xsavec )
+            {
+                ptr->xsave_hdr.xcomp_bv &= this_cpu(xcr0) | this_cpu(xss);
+                ptr->xsave_hdr.xstate_bv &= ptr->xsave_hdr.xcomp_bv;
+                ptr->xsave_hdr.xcomp_bv |= XSTATE_COMPACTION_ENABLED;
+            }
+            else
+            {
+                ptr->xsave_hdr.xstate_bv &= this_cpu(xcr0);
+                ptr->xsave_hdr.xcomp_bv = 0;
+            }
+            memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved));
+            continue;
+        case 2:
+            /* Stage 2: Reset all state. */
+            ptr->fpu_sse.mxcsr = MXCSR_DEFAULT;
+            ptr->xsave_hdr.xstate_bv = 0;
+            ptr->xsave_hdr.xcomp_bv = cpu_has_xsaves
+                                      ? XSTATE_COMPACTION_ENABLED : 0;
+            continue;
+        default:
+            domain_crash(current->domain);
+            break;
+        }
     }
 }
 
@@ -496,6 +549,8 @@  void xstate_init(struct cpuinfo_x86 *c)
 
     if ( bsp )
     {
+        static typeof(current->arch.xsave_area->fpu_sse) __initdata ctxt;
+
         xfeature_mask = feature_mask;
         /*
          * xsave_cntxt_size is the max size required by enabled features.
@@ -504,6 +559,10 @@  void xstate_init(struct cpuinfo_x86 *c)
         xsave_cntxt_size = _xstate_ctxt_size(feature_mask);
         printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
             __func__, xsave_cntxt_size, xfeature_mask);
+
+        asm ( "fxsave %0" : "=m" (ctxt) );
+        if ( ctxt.mxcsr_mask )
+            mxcsr_mask = ctxt.mxcsr_mask;
     }
     else
     {