From patchwork Sun Feb 2 14:32:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Guillaume X-Patchwork-Id: 13956531 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CF8F2C0218F for ; Sun, 2 Feb 2025 14:33:00 +0000 (UTC) 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 X-Outflank-Mailman: Message body and most headers restored to incoming version 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-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 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: ``` 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 --- 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",