Re: Xen panic due to xstate mismatch

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

This is a sanity check that an algorithm in Xen matches hardware.  It is only compiled into debug builds by default. 

Given that you're running under virtualbox, i have a suspicion as to what's wrong.

Can you collect the full `xen-cpuid -p` output from within your environment?  I don't believe you're suggested code change is correct, but it will good enough to get these diagnostics.

~Andrew

On Sun, 2 Feb 2025, 15:32 Guillaume, <thouveng@xxxxxxxxx> wrote:

Hello,

 I'd like to report an issue I encountered when building Xen from source. To give you some context, During the Xen winter meetup in Grenoble few days ago, there was a discussion about strengthening collaboration between Xen and academia. One issue raised by a professor was that Xen is harder for students to install and experiment compared to KVM. In response it was mentionned that Debian packages are quite decent. This motivated me to try installing and playing with Xen myself. While I am familiar with Xen (I work on the XAPI toolstack at Vates) I'm not deeply familiar with its internals, so this seemed like a good learning opportunity and maybe some contents for some blog posts :).

 I set up a Debian testing VM on Virtualbox and installed Xen from packages. Everything worked fine: Grub was updated, I rebooted, and I had a functional Xen setup with xl running in Dom0.

 Next I download the last version of Xen from xenbits.org, and built only the hypervisor (no tools, no stubdom) , using the same configuration as the Debian package (which is for Xen 4.19). After updating GRUB and rebooting, Xen failed to boot. Fortunately, I was able to capture the following error via `ttyS0`:

```
(XEN) [0000000d2c23739a] xstate: size: 0x340 and states: 0x7
(XEN) [0000000d2c509c1d]
(XEN) [0000000d2c641ffa] ****************************************
(XEN) [0000000d2c948e3b] Panic on CPU 0:
(XEN) [0000000d2cb349bb] XSTATE 0x0000000000000003, uncompressed hw size 0x340 != xen size 0x240
(XEN) [0000000d2cfc5786] ****************************************
(XEN) [0000000d2d308c24]
```
From my understanding, the hardware xstate size (`hw_size`) represents the maximum memory required for the `XSAVE/XRSTOR` save area, while `xen_size` is computed by summing the space required for the enabled features. In `xen/arch/x86/xstate.c`, if these sizes do not match, Xen panics. However, wouldn’t it be correct for `xen_size` to be **less than or equal to** `hw_size` instead of exactly matching?

I tested the following change:

```
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -710,7 +710,7 @@ static void __init check_new_xstate(struct xcheck_state *s, uint64_t new)
      */
     xen_size = xstate_uncompressed_size(s->states & X86_XCR0_STATES);

-    if ( xen_size != hw_size )
+    if ( xen_size > hw_size )
         panic("XSTATE 0x%016"PRIx64", uncompressed hw size %#x != xen size %#x\n",
               s->states, hw_size, xen_size);
```

With this change, Xen boots correctly, but I may be missing some side effects...
Additionally, I am confused as to why this issue does not occur with the default Debian Xen package. Even when I rebuild Xen 4.19.1 from source (the same version as the package), I still encounter the issue.

So I have two questions:
- Is my understanding correct that xen_size <= hw_size should be allowed?
- Are there any potential side effects of this change?

- Bonus: Have some of you any explanations about why does the issue not occur with the packaged version of Xen but does with a self-built version?

Hope I wasn't too long and thanks for taking the time to read this,

Best regards,

Guillaume