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, <thouv...@gmail.com> 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
>
