From nobody Fri Mar 14 06:30:01 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1738506788; cv=none; d=zohomail.com; s=zohoarc; b=Crvgz093mu0ANmhElwkIY1/8Dmmt61Ufa3atGn2pInYgv8BDcVpWosB1/acsKF3B5WcT6azc6+FCy8f2XIKlUqZsMdnVKujvPAh+iYBDgzj7tMA7rD/KmHJc96YBa28d12v1Iy4RRK7X6ySfioPJfMf+mBTUEn6ykg/u5rPEaaU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1738506788; h=Content-Type:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=kcgYUxWIdN1YYjYkqm50dtEfNs0UeQl9JAGAYSSgupY=; b=f+AKJW7SQY6o10Qu2Kz5P7XseP0Gm/JSbS6bxzMmDswbP2NZCPGMU5R7Vx2yAyj/QmLNRcZyVP+/6if/vN5TOgHpRdUQR3gWg8jxueGPJwocC08q3sYIyPoNaGau5/X48kc50Vr7w8CqypM9Y/chMSgDfs3hqFgjaHnflADt+RA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1738506788754840.9463084724646; Sun, 2 Feb 2025 06:33:08 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.880372.1290444 (Exim 4.92) (envelope-from ) id 1teb1g-0000Sf-Kn; Sun, 02 Feb 2025 14:32:44 +0000 Received: by outflank-mailman (output) from mailman id 880372.1290444; Sun, 02 Feb 2025 14:32:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1teb1g-0000SY-I6; Sun, 02 Feb 2025 14:32:44 +0000 Received: by outflank-mailman (input) for mailman id 880372; Sun, 02 Feb 2025 14:32:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1teb1f-0000SS-69 for xen-devel@lists.xenproject.org; Sun, 02 Feb 2025 14:32:43 +0000 Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [2001:4860:4864:20::33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8e53ef9c-e172-11ef-99a4-01e77a169b0f; Sun, 02 Feb 2025 15:32:41 +0100 (CET) Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-29f88004a92so2003516fac.1 for ; Sun, 02 Feb 2025 06:32:40 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e53ef9c-e172-11ef-99a4-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738506759; x=1739111559; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=kcgYUxWIdN1YYjYkqm50dtEfNs0UeQl9JAGAYSSgupY=; b=W4+iIj5FiVzcXmMhJ4iQcY2y6mM9GG9US84TX75p5a2D1iEc6TMbO+xZ3Ysrjf6rMH 1TwNNKkYDByn8oZHByqYmNmkgylQ+Qvkoe/Aw/4dt2QZdT8wr1A9GVcc5gVNcSDdW9Bz Xkw72nITnJJvI3fV4vJOftR9mADuPG5T1xlbnpOjb63203z8DOi8eqHUP9AmkQ+LJlC5 0KGnKbAzoJhiMU8xr33cd7EzilM1bVPxxXRPsjMPu59Bl2AyBPTmf7soX+KvsUeRaa3c TYLrXiYHecx4j+WrkRMMfPDyLz63qZGXf9GLQpXZyZZujYe84fS41w/gmVJca3CFrY2R qBRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738506759; x=1739111559; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kcgYUxWIdN1YYjYkqm50dtEfNs0UeQl9JAGAYSSgupY=; b=qLxv1lcuD2svEcaVczmsyaEfwu/+IGbQ0pJWA0ia9+pUiNGk8Tu/VoYAoZD9UTY+84 K24qYlH4+4WP8A3OM5krRPNz8mifnnAAxdQKJTp45NkhSYRtzKuffc/X7/A4yUug8sbT jgDlXzuJHu5JUoFyv1h2pA50KyiOcgdnuTUBEdbH2CB/I7u5cQ3vKUAFVACRPc6wrnKM yftKmXFdafA04u5v9mKoVk+uApC4iXgEQOQYt/kDB1zb4sATMAzfxGeunf64eNS56X0f T+qH2nrViB7xityef+lRuKkuTwG1mM0DmnkW2NypehPZMtz2TMHdJ6JpACqCnmWQ0GrL uNmQ== X-Gm-Message-State: AOJu0Yw7m+UOAQEMBwaVlE1RKX70pQexluLkPH8sJsuvi+n13tD3r4mS VHz7w3yB8v+k73czsI3VibPMvlJlVqiM/IFkkLp3XmlitMEswdsJqp86Lz2tN4VRgdzH994HPgT tsGReamZp6+2QTNyHXhEFTQuCl8sq4srC X-Gm-Gg: ASbGncvMiPTPfAFMBM2URfIfTq6fq75XkiMIZY7h1AkcLs1V2+kGsoPX104ywkp/FKf SdTETleAiDGk6AdYaX4Zk/RceAlvh9lqR/YF9E0VSy0poZAQTo6kbzSosj2Ms3T1zbITmKd1MyA == X-Google-Smtp-Source: AGHT+IHPLXuHPkIlNF/nmnTLoHFMsKlG6R3ImESUBrJA6SaLCVxSTO/X5r9OxcYQgNjg6IfhwdZXHT7W0iqR0SWehhk= X-Received: by 2002:a05:6870:ecac:b0:29e:5e83:150e with SMTP id 586e51a60fabf-2b32f2926bfmr12053991fac.27.1738506759438; Sun, 02 Feb 2025 06:32:39 -0800 (PST) MIME-Version: 1.0 From: Guillaume Date: Sun, 2 Feb 2025 15:32:03 +0100 X-Gm-Features: AWEUYZnGfc9bI9ljdSGnO_tzlBSMDceljRTElW2V_yzSwIREjY2X3_QCUekU6lo Message-ID: Subject: Xen panic due to xstate mismatch To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d60ecd062d29a59c" X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1738506791798019000 --000000000000d60ecd062d29a59c Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 !=3D 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=E2=80=99t 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 =3D xstate_uncompressed_size(s->states & X86_XCR0_STATES); - if ( xen_size !=3D hw_size ) + if ( xen_size > hw_size ) panic("XSTATE 0x%016"PRIx64", uncompressed hw size %#x !=3D xen si= ze %#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 <=3D 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 --000000000000d60ecd062d29a59c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>
Hello,

=C2=A0I'd like to report an issue I e= ncountered when building Xen from source. To give you some context, During = the Xen winter meetup in Grenoble few days ago, there was a discussion abou= t 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 qui= te 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 learn= ing opportunity and maybe some contents for some blog posts :).

=C2=A0I set up a Debian testing VM on Virtualbox and installed Xen from p= ackages. Everything worked fine: Grub was updated, I rebooted, and I had a = functional Xen setup with xl running in Dom0.
=C2=A0Next I downloa= d the last version of Xen from xenbits.org, and built <= span class=3D"gmail-hljs-keyword">only the hypervisor (no tools, no = stubdom) , using the same configuration as the Debian package (which is for Xen 4.19). Af= ter updating GRUB and rebo= oting, Xen failed to boot. Fortun= ately, I was able to capture the = following error via `ttyS0`:```
(XEN) [0000000d2c23739a] xstate: size: 0x340 and states: 0x7
(XE= N) [0000000d2c509c1d]
(XEN) [0000000d2c641ffa] *************************= ***************
(XEN) [0000000d2c948e3b] Panic on CPU 0:
(XEN) [00000= 00d2cb349bb] XSTATE 0x0000000000000003, uncompressed hw size 0x340 !=3D xen= size 0x240
(XEN) [0000000d2cfc5786] ***********************************= *****
(XEN) [0000000d2d308c24]
```
From my understanding, the hardware xstate size (`hw_size`) represe= nts the maximum memory required <= span class=3D"gmail-hljs-keyword">for the `XSAVE/XRSTOR` save area, wh= ile `xen_size` is computed by summing the space required for the enabled fe= atures. In `xen/arch/x86/xs= tate.c`, if these sizes do not match, Xen panics. However, woul= dn=E2=80=99t it be correct for `x= en_size` to be **less than or eq= ual to** `hw_size` instead of ex= actly matching?

I t= ested 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)
=C2=A0 =C2=A0 =C2=A0 */=C2=A0 =C2=A0 =C2=A0xen_size =3D xstate_uncompressed_size(s->states &am= p; X86_XCR0_STATES);

- =C2=A0 =C2=A0if ( xen_size !=3D hw_size )
= + =C2=A0 =C2=A0if ( xen_size > hw_size )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0panic("XSTATE 0x%016"PRIx64", uncompressed hw size %#x= !=3D xen size %#x\n",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0s->states, hw_size, xen_size);
```
With this ch= ange, Xen boots correctly, but I may be missing some side effects...
Ad= ditionally, I am confused as to why this issue does not oc= cur with the default Debian Xen package. Even when I rebuild Xen 4.= 19.1 from source (the same version as the package), I still encoun= ter the issue.
So I have two questions:
- Is my understand= ing correct that xen_size <=3D hw_size should be allowed?- Are there any potential side effects of this change?
- Bo= nus: Have some of you any explanations about why does the issue not occur w= ith 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 t= his,
Best regards,

Guillaume
--000000000000d60ecd062d29a59c--