Message ID | 20230405183942.734019-1-fenghua.yu@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp528883vqo; Wed, 5 Apr 2023 12:05:15 -0700 (PDT) X-Google-Smtp-Source: AKy350aYhmscu/2CxLVnKJw7HWIklRpCw8q0WaQ4fi29wIQTPVGU/lkHaeWVpVHlGg0uTKOLDdTg X-Received: by 2002:a17:90b:33cf:b0:23e:fa90:ba34 with SMTP id lk15-20020a17090b33cf00b0023efa90ba34mr8301292pjb.37.1680721515680; Wed, 05 Apr 2023 12:05:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680721515; cv=none; d=google.com; s=arc-20160816; b=AgEUE4xJa1Pb9T6NHAxdaEMIsJepEAcyBQBdfkCooiSAanOMmPYpyurLeMNjXo8gxD l24DhM6DXi4ot332CSW4Z7eM2oysbCnpjDHa4wqxEhkPdRpSCRyRmErTTk5qndgdExb6 yDnu7wCTLAb7Eqdz0ab3CJmE6K+IoLqhJ31IYrNlBJxeade3LrPhCoDRz0Ck/k0blGkK XTF/3oHoC0tYoHR1DqgQye/DjdXCSzd8tDVt8ntdAzGeCAt+uM7Jm70GZUxWceTcb3FG h8x6qqMLZQUW9h9G6jUwLvbar0glhkeqlrqioodlnPsv62RDaLL/YEX43JiC9XIRwU2P /6YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=y5yka+P0wk0Hdnp0KiXOIPkFZdTmn5rhO8fKxmczuI4=; b=kMbUMFHeP0dVtMMmbXvfTKOEsJ5tyCBTD8g4FYL1I1PWsvU63dUpgH8jUsNlCwGZNz y0D/E03KWDm3FFLe9Fu2IuPqascdKZgvYNbZn221GMhsKJ5T3bMIHrlhSfz+7rwx4XYk 9dM3KP2vb7APM4YVdGxOy6N7lsPURAo1pg+dVM+e4EQ9UfTCM9lkMTM129QGmjBvCxwS XtFAt5b3Ftnf1WDanZ0A7v4d7D5pEz3ZC9j+v1F5USOymKeRQhLhh64HN6CTNqQRboPq QG5FzBtLhKEAmVIoOk+Ar8bsuvFm1aHaX3VCAtq99hBSLGSO6n+c02z9gvv2gdAZlL0O rwXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LXnOPxTF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pg14-20020a17090b1e0e00b0023f9cb53c90si2008803pjb.70.2023.04.05.12.04.57; Wed, 05 Apr 2023 12:05:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LXnOPxTF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232896AbjDESkX (ORCPT <rfc822;lkml4gm@gmail.com> + 99 others); Wed, 5 Apr 2023 14:40:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234175AbjDESkT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 5 Apr 2023 14:40:19 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14E9E6194 for <linux-kernel@vger.kernel.org>; Wed, 5 Apr 2023 11:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680720014; x=1712256014; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=zgirNs/yy9kf5VlqEnEGs45ztndGGwdnGjYncEsTT3U=; b=LXnOPxTF41AHdN3THl750QLPTzeRdHPnqRaorr5QGds86ddLxubZWaHX XbKSdsxEuhAntlGOoqR0nlsSxXZFftgDgf+LSbn2sSQ767TX1vVvbcOZ/ Y0IWPb5XtWXnoNMONekCjHCY43JtnImUN0PflQVCWnamwqg2lXg7YjzTt Wl9hycpO3AcNmB23pm2ACSBXuk7JqAdYUt8Flq6wh9MBk5/MZs7Hh1GM5 VL7zwwFt/tHPoD+yZlwPa+x/sgtfFdLgYfy1wFH+4zcgXBUprN8Nwu8Ck QlX8YyE+0813OyJf9p8EdJnyrDjsw5gyOoK0WCD9jCteC7QdwECPsZ3Dt A==; X-IronPort-AV: E=McAfee;i="6600,9927,10671"; a="340030870" X-IronPort-AV: E=Sophos;i="5.98,321,1673942400"; d="scan'208";a="340030870" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2023 11:40:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10671"; a="636993556" X-IronPort-AV: E=Sophos;i="5.98,321,1673942400"; d="scan'208";a="636993556" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orsmga003.jf.intel.com with ESMTP; 05 Apr 2023 11:40:12 -0700 From: Fenghua Yu <fenghua.yu@intel.com> To: "Dave Hansen" <dave.hansen@linux.intel.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Borislav Petkov" <bp@alien8.de>, "Ingo Molnar" <mingo@redhat.com> Cc: "linux-kernel" <linux-kernel@vger.kernel.org>, "x86" <x86@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>, Chintan M Patel <chintan.m.patel@intel.com> Subject: [RFC PATCH] x86/fpu/xstate: Add more diagnostic information on inconsistent xstate sizes Date: Wed, 5 Apr 2023 11:39:42 -0700 Message-Id: <20230405183942.734019-1-fenghua.yu@intel.com> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762364244254017619?= X-GMAIL-MSGID: =?utf-8?q?1762364244254017619?= |
Series |
[RFC] x86/fpu/xstate: Add more diagnostic information on inconsistent xstate sizes
|
|
Commit Message
Fenghua Yu
April 5, 2023, 6:39 p.m. UTC
A warning is emitted when xstate sizes are found inconsistent. But the warning message doesn't show enough information to diagnose the issue. Provide more detailed xstate size information to help debug the issue. As a hypothetical example, on a platform that may report incorrect xstate size in CPUID.0xd.1:EBX, the diagnostic information after the warning will show: [ 0.000000] x86/fpu: max_features=0x407 [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.000000] x86/fpu: xstate_offset[10]: 832, xstate_sizes[10]: 8 [ 0.000000] x86/fpu: total size: 840 bytes [ 0.000000] x86/fpu: XCR0=0x7, IA32_XSS=0x400 [ 0.000000] x86/fpu: kernel_size from CPUID.0xd.0x1:EBX: 576 bytes XCR0 | IA32_XSS is 0x407 which is consistent with max_features. CPUID.0xd.0x1:EBX should report the size of the xsave area containing xstate components corresponding to bits set in XCR0 | IA32_XSS. But it only reports 576 bytes of xsave area which doesn't count xstate sizes for AVX (offset 2 and 256 bytes) and PASID (offset 10 and 8 bytes). This confirms that the platform reports xstate size incorrectly through the CPUID bits. Suggest-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Chintan M Patel <chintan.m.patel@intel.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> --- arch/x86/kernel/fpu/xstate.c | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-)
Comments
On 4/5/2023 11:39 AM, Fenghua Yu wrote: > A warning is emitted when xstate sizes are found inconsistent. > But the warning message doesn't show enough information to diagnose > the issue. > > Provide more detailed xstate size information to help debug the issue. > As a hypothetical example, on a platform that may report incorrect > xstate size in CPUID.0xd.1:EBX, the diagnostic information after > the warning will show: > [ 0.000000] x86/fpu: max_features=0x407 > [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 > [ 0.000000] x86/fpu: xstate_offset[10]: 832, xstate_sizes[10]: 8 > [ 0.000000] x86/fpu: total size: 840 bytes > [ 0.000000] x86/fpu: XCR0=0x7, IA32_XSS=0x400 > [ 0.000000] x86/fpu: kernel_size from CPUID.0xd.0x1:EBX: 576 bytes > > XCR0 | IA32_XSS is 0x407 which is consistent with max_features. > CPUID.0xd.0x1:EBX should report the size of the xsave area > containing xstate components corresponding to bits set in > XCR0 | IA32_XSS. But it only reports 576 bytes of xsave area which > doesn't count xstate sizes for AVX (offset 2 and 256 bytes) and > PASID (offset 10 and 8 bytes). This confirms that the platform > reports xstate size incorrectly through the CPUID bits. > > Suggest-by: Dave Hansen <dave.hansen@linux.intel.com> > Tested-by: Chintan M Patel <chintan.m.patel@intel.com> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> > --- > arch/x86/kernel/fpu/xstate.c | 33 +++++++++++++++++++++++++++++++-- > 1 file changed, 31 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c > index 0bab497c9436..5f27fcdc6c90 100644 > --- a/arch/x86/kernel/fpu/xstate.c > +++ b/arch/x86/kernel/fpu/xstate.c > @@ -602,8 +602,37 @@ static bool __init paranoid_xstate_size_valid(unsigned int kernel_size) > } > } > size = xstate_calculate_size(fpu_kernel_cfg.max_features, compacted); > - XSTATE_WARN_ON(size != kernel_size, > - "size %u != kernel_size %u\n", size, kernel_size); > + if (size != kernel_size) { > + u64 xcr0, ia32_xss; > + > + XSTATE_WARN_ON(1, "size %u != kernel_size %u\n", > + size, kernel_size); > + > + /* Show more information to help diagnose the size issue. */ > + pr_info("x86/fpu: max_features=0x%llx\n", > + fpu_kernel_cfg.max_features); > + print_xstate_offset_size(); > + pr_info("x86/fpu: total size: %u bytes\n", size); > + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); > + if (compacted) { > + rdmsrl(MSR_IA32_XSS, ia32_xss); This shouldn't be directly read here because of the LBR state component. See the function comment: * Independent XSAVE features allocate their own buffers and are not * covered by these checks. Only the size of the buffer for task->fpu * is checked here. But, isn't that max_features bitmask pretty much about it? > + pr_info("x86/fpu: XCR0=0x%llx, IA32_XSS=0x%llx\n", > + xcr0, ia32_xss); > + } else { > + pr_info("x86/fpu: XCR0=0x%llx\n", xcr0); > + } > + /* > + * In compact case, CPUID.0xd.0x1:EBX reports the size of > + * the XSAVE size containing all the state components > + * corresponding to bits set in XCR0 | IA32_XSS. > + * > + * Otherwise, CPUID.0xd.0x0:EBX reports the size of an XSAVE > + * area containing all the *user* state components > + * corresponding to bits set in XCR0. > + */ > + pr_info("x86/fpu: kernel_size from CPUID.0xd.0x%x:EBX: %u bytes\n", > + compacted ? 1 : 0, kernel_size); Include Thiago who asked this. Thanks, Chang
Hi, Chang, On 4/7/23 11:22, Chang S. Bae wrote: > On 4/5/2023 11:39 AM, Fenghua Yu wrote: >> A warning is emitted when xstate sizes are found inconsistent. >> But the warning message doesn't show enough information to diagnose >> the issue. >> >> Provide more detailed xstate size information to help debug the issue. >> As a hypothetical example, on a platform that may report incorrect >> xstate size in CPUID.0xd.1:EBX, the diagnostic information after >> the warning will show: >> [ 0.000000] x86/fpu: max_features=0x407 >> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 >> [ 0.000000] x86/fpu: xstate_offset[10]: 832, xstate_sizes[10]: 8 >> [ 0.000000] x86/fpu: total size: 840 bytes >> [ 0.000000] x86/fpu: XCR0=0x7, IA32_XSS=0x400 >> [ 0.000000] x86/fpu: kernel_size from CPUID.0xd.0x1:EBX: 576 bytes >> >> XCR0 | IA32_XSS is 0x407 which is consistent with max_features. >> CPUID.0xd.0x1:EBX should report the size of the xsave area >> containing xstate components corresponding to bits set in >> XCR0 | IA32_XSS. But it only reports 576 bytes of xsave area which >> doesn't count xstate sizes for AVX (offset 2 and 256 bytes) and >> PASID (offset 10 and 8 bytes). This confirms that the platform >> reports xstate size incorrectly through the CPUID bits. >> >> Suggest-by: Dave Hansen <dave.hansen@linux.intel.com> >> Tested-by: Chintan M Patel <chintan.m.patel@intel.com> >> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> >> --- >> arch/x86/kernel/fpu/xstate.c | 33 +++++++++++++++++++++++++++++++-- >> 1 file changed, 31 insertions(+), 2 deletions(-) >> >> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c >> index 0bab497c9436..5f27fcdc6c90 100644 >> --- a/arch/x86/kernel/fpu/xstate.c >> +++ b/arch/x86/kernel/fpu/xstate.c >> @@ -602,8 +602,37 @@ static bool __init >> paranoid_xstate_size_valid(unsigned int kernel_size) >> } >> } >> size = xstate_calculate_size(fpu_kernel_cfg.max_features, >> compacted); >> - XSTATE_WARN_ON(size != kernel_size, >> - "size %u != kernel_size %u\n", size, kernel_size); >> + if (size != kernel_size) { >> + u64 xcr0, ia32_xss; >> + >> + XSTATE_WARN_ON(1, "size %u != kernel_size %u\n", >> + size, kernel_size); >> + >> + /* Show more information to help diagnose the size issue. */ >> + pr_info("x86/fpu: max_features=0x%llx\n", >> + fpu_kernel_cfg.max_features); >> + print_xstate_offset_size(); >> + pr_info("x86/fpu: total size: %u bytes\n", size); >> + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); >> + if (compacted) { >> + rdmsrl(MSR_IA32_XSS, ia32_xss); > > This shouldn't be directly read here because of the LBR state component. > > See the function comment: > > * Independent XSAVE features allocate their own buffers and are not > * covered by these checks. Only the size of the buffer for task->fpu > * is checked here. > > But, isn't that max_features bitmask pretty much about it? How about getting IA32_XSS from xfeatures_mask_supervisor()? That's how to get kernel_size by setting IA32_XSS without independent features in get_xsave_compacted_size(). Thanks. -Fenghua
On 4/10/2023 1:43 PM, Fenghua Yu wrote: > On 4/7/23 11:22, Chang S. Bae wrote: >> On 4/5/2023 11:39 AM, Fenghua Yu wrote: >>> >>> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c >>> index 0bab497c9436..5f27fcdc6c90 100644 >>> --- a/arch/x86/kernel/fpu/xstate.c >>> +++ b/arch/x86/kernel/fpu/xstate.c >>> @@ -602,8 +602,37 @@ static bool __init >>> paranoid_xstate_size_valid(unsigned int kernel_size) >>> } >>> } >>> size = xstate_calculate_size(fpu_kernel_cfg.max_features, >>> compacted); >>> - XSTATE_WARN_ON(size != kernel_size, >>> - "size %u != kernel_size %u\n", size, kernel_size); >>> + if (size != kernel_size) { >>> + u64 xcr0, ia32_xss; >>> + >>> + XSTATE_WARN_ON(1, "size %u != kernel_size %u\n", >>> + size, kernel_size); >>> + >>> + /* Show more information to help diagnose the size issue. */ >>> + pr_info("x86/fpu: max_features=0x%llx\n", >>> + fpu_kernel_cfg.max_features); >>> + print_xstate_offset_size(); >>> + pr_info("x86/fpu: total size: %u bytes\n", size); >>> + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); >>> + if (compacted) { >>> + rdmsrl(MSR_IA32_XSS, ia32_xss); >> >> This shouldn't be directly read here because of the LBR state component. >> >> See the function comment: >> >> * Independent XSAVE features allocate their own buffers and are not >> * covered by these checks. Only the size of the buffer for task->fpu >> * is checked here. >> >> But, isn't that max_features bitmask pretty much about it? > > How about getting IA32_XSS from xfeatures_mask_supervisor()? That's how > to get kernel_size by setting IA32_XSS without independent features in > get_xsave_compacted_size() I think what it tests here is comparing the sizes between the kernel code and microcode calculations on the same input, which is the max_features bitmask. We know that the kernel code calculates the size based on it and also takes it to write down there -- XCR0 and IA32_XSS. Then, showing that bitmask looks to be enough I thought, no? I still expect some acknowledgment of what is coded here for the kernel calculation details. Thanks, Chang
Hi, Chang, On 4/11/23 09:29, Chang S. Bae wrote: > On 4/10/2023 1:43 PM, Fenghua Yu wrote: >> On 4/7/23 11:22, Chang S. Bae wrote: >>> On 4/5/2023 11:39 AM, Fenghua Yu wrote: >>>> >>>> diff --git a/arch/x86/kernel/fpu/xstate.c >>>> b/arch/x86/kernel/fpu/xstate.c >>>> index 0bab497c9436..5f27fcdc6c90 100644 >>>> --- a/arch/x86/kernel/fpu/xstate.c >>>> +++ b/arch/x86/kernel/fpu/xstate.c >>>> @@ -602,8 +602,37 @@ static bool __init >>>> paranoid_xstate_size_valid(unsigned int kernel_size) >>>> } >>>> } >>>> size = xstate_calculate_size(fpu_kernel_cfg.max_features, >>>> compacted); >>>> - XSTATE_WARN_ON(size != kernel_size, >>>> - "size %u != kernel_size %u\n", size, kernel_size); >>>> + if (size != kernel_size) { >>>> + u64 xcr0, ia32_xss; >>>> + >>>> + XSTATE_WARN_ON(1, "size %u != kernel_size %u\n", >>>> + size, kernel_size); >>>> + >>>> + /* Show more information to help diagnose the size issue. */ >>>> + pr_info("x86/fpu: max_features=0x%llx\n", >>>> + fpu_kernel_cfg.max_features); >>>> + print_xstate_offset_size(); >>>> + pr_info("x86/fpu: total size: %u bytes\n", size); >>>> + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); >>>> + if (compacted) { >>>> + rdmsrl(MSR_IA32_XSS, ia32_xss); >>> >>> This shouldn't be directly read here because of the LBR state component. >>> >>> See the function comment: >>> >>> * Independent XSAVE features allocate their own buffers and are not >>> * covered by these checks. Only the size of the buffer for task->fpu >>> * is checked here. >>> >>> But, isn't that max_features bitmask pretty much about it? >> >> How about getting IA32_XSS from xfeatures_mask_supervisor()? That's >> how to get kernel_size by setting IA32_XSS without independent >> features in get_xsave_compacted_size() > I think what it tests here is comparing the sizes between the kernel > code and microcode calculations on the same input, which is the > max_features bitmask. > > We know that the kernel code calculates the size based on it and also > takes it to write down there -- XCR0 and IA32_XSS. Then, showing that > bitmask looks to be enough I thought, no? First of all, max_features is shown already. Kernel_size from CPUID.0xd.0x1:EBX takes XCR0 | IA32_XSS as input. Platform may take wrong XCR0 or IA32_XSS and get wrong kernel_size. The purpose of this patch is to provide more debug info to help debug platform/kernel issue. So instead of a whole max_features, xgetbv() to get XCR0 and xfeatures_mask_supervisor() to get IA32_XSS provides more debug info in case platform may have issue in XCR0 or IA32_XSS. In other words, splitting max_features into XCR0 and IA32_XSS and showing them individually provide more useful debug info than one single max_features value. Does it make sense? > > I still expect some acknowledgment of what is coded here for the kernel > calculation details. The kernel calculation is shown in + print_xstate_offset_size(); + pr_info("x86/fpu: total size: %u bytes\n", size); Isn't that detailed enough to show offset and size of each xstate and sum of sizes? After that, + pr_info("x86/fpu: kernel_size from CPUID.0xd.0x%x:EBX: %u bytes\n", + compacted ? 1 : 0, kernel_size); shows how kernel_size is calculated from CPUID? Using the above debug info, a real platform CPUID issue is shown clearly. What other details are needed? Thanks. -Fenghua
On 4/11/2023 6:21 PM, Fenghua Yu wrote: > > First of all, max_features is shown already. Yes. > Kernel_size from CPUID.0xd.0x1:EBX takes XCR0 | IA32_XSS as input. > Platform may take wrong XCR0 or IA32_XSS and get wrong kernel_size. The > purpose of this patch is to provide more debug info to help debug > platform/kernel issue. So instead of a whole max_features, xgetbv() to > get XCR0 and xfeatures_mask_supervisor() to get IA32_XSS provides more > debug info in case platform may have issue in XCR0 or IA32_XSS. > > In other words, splitting max_features into XCR0 and IA32_XSS and > showing them individually provide more useful debug info than one single > max_features value. > > Does it make sense? Hmm, I don't get it. I don't think whether the microcode takes those register values wrong or miscalculates the size does matter here. print_xstate_offset_size() or something can decode the mask and readily shows off how it was calculated here. Then, probably that's it. >> I still expect some acknowledgment of what is coded here for the >> kernel calculation details. > > The kernel calculation is shown in > + print_xstate_offset_size(); > + pr_info("x86/fpu: total size: %u bytes\n", size); > > Isn't that detailed enough to show offset and size of each xstate and > sum of sizes? > > After that, > + pr_info("x86/fpu: kernel_size from CPUID.0xd.0x%x:EBX: %u bytes\n", > + compacted ? 1 : 0, kernel_size); > shows how kernel_size is calculated from CPUID? > > Using the above debug info, a real platform CPUID issue is shown clearly. > > What other details are needed? I recall it was also asked to show which features are off or mismatched as compared to the CPU calculation. I'm not so sure about it. Thanks, Chang
On 4/11/23 18:21, Fenghua Yu wrote: > In other words, splitting max_features into XCR0 and IA32_XSS and > showing them individually provide more useful debug info than one single > max_features value. > > Does it make sense? Not to me. >> I still expect some acknowledgment of what is coded here for the >> kernel calculation details. > > The kernel calculation is shown in > + print_xstate_offset_size(); > + pr_info("x86/fpu: total size: %u bytes\n", size); > > Isn't that detailed enough to show offset and size of each xstate and > sum of sizes? > > After that, > + pr_info("x86/fpu: kernel_size from CPUID.0xd.0x%x:EBX: %u bytes\n", > + compacted ? 1 : 0, kernel_size); > shows how kernel_size is calculated from CPUID? > > Using the above debug info, a real platform CPUID issue is shown clearly. > > What other details are needed? I was kinda hoping this would be a simple, non-controversial patch that would get us better debugging info the next time that the microcode or a bad VMM screws up. This patch isn't turning out to be as simple as I hoped. I was wrong. Let's just drop this.
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 0bab497c9436..5f27fcdc6c90 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -602,8 +602,37 @@ static bool __init paranoid_xstate_size_valid(unsigned int kernel_size) } } size = xstate_calculate_size(fpu_kernel_cfg.max_features, compacted); - XSTATE_WARN_ON(size != kernel_size, - "size %u != kernel_size %u\n", size, kernel_size); + if (size != kernel_size) { + u64 xcr0, ia32_xss; + + XSTATE_WARN_ON(1, "size %u != kernel_size %u\n", + size, kernel_size); + + /* Show more information to help diagnose the size issue. */ + pr_info("x86/fpu: max_features=0x%llx\n", + fpu_kernel_cfg.max_features); + print_xstate_offset_size(); + pr_info("x86/fpu: total size: %u bytes\n", size); + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK); + if (compacted) { + rdmsrl(MSR_IA32_XSS, ia32_xss); + pr_info("x86/fpu: XCR0=0x%llx, IA32_XSS=0x%llx\n", + xcr0, ia32_xss); + } else { + pr_info("x86/fpu: XCR0=0x%llx\n", xcr0); + } + /* + * In compact case, CPUID.0xd.0x1:EBX reports the size of + * the XSAVE size containing all the state components + * corresponding to bits set in XCR0 | IA32_XSS. + * + * Otherwise, CPUID.0xd.0x0:EBX reports the size of an XSAVE + * area containing all the *user* state components + * corresponding to bits set in XCR0. + */ + pr_info("x86/fpu: kernel_size from CPUID.0xd.0x%x:EBX: %u bytes\n", + compacted ? 1 : 0, kernel_size); + } return size == kernel_size; }