[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 20 Apr 2021 10:41:35 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0FTGKve+mIVo6Wdh2PnAJXmIHEw1Ia0RVE5qAT5dKs8=; b=oH0MS8Gpj1q3xx2QFUXSAHGVVCH9qgTYEBtsYR5cY156RIcZ/JGmU+4hHotc2L7haToRcjJf3cyhmkBRPljX5v3CSpSFtLw6r+qSIhuTt0fdsnsGAIRUV7v8GhxpOUzAg4vkYjlEnq9lPuPJuqv8yl6LUS1rJNwwMn1uugbmzXoQADxVlvczWulwlepAZikGV9C7cc3joFlGftvtaaI5O1TivAXHhi+TQqLwJTnVFom/tZxVJpe7MIA54y1hnsLZzSyM8Td39TOqmJqXZrkeUk0orxPn6KG0j+o9HLhM50F3dDYwRWiSUZhCAfRcTDT++gdJRN8xiTbgnc5a5bGJDg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=du+hIS8LrZAxFj+TzIib407gwfzfCllDkcMuMnAgomXgx149CgfHnhOGEhSMxCk3yrng9zWKNTvE7g1O8syes/zcLXHNYUJ/GqLxg7n9oXgn/Dh8dxNtgE7vzqYyA4zEvlQfuYUjpcckJY3WsFbY0U2s1aBu/HuNWK2n/vK/8CUQCiW8c6iX7ZEoClah+EZ/evUib70Mkj6N+pt7ba8WTD2uQuDJEWOzK+rCHS+C54Nwj9EbZqL9NiDXZUUTizyGhX5WGyVP0w9T6J3jTIZIycCKVzKeT2xhOPGrhji3oJRecQvFj5W7h7jcBklEA6X5kcJcFH4KrAppC/VLRd+2kw==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Tue, 20 Apr 2021 08:41:56 +0000
  • Ironport-hdrordr: A9a23:uTpniK6ybjtNuGDW7wPXwXqEI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoex3h3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdBHW3tV2kZ 1te60WMrHNJHBnkMf35xS5Gd48wN+BtJuln/va0m0Fd2FXQotLhj0JbDqzOEtwWQVAGN4VFI CE4NBGujqnfh0sH7mGL1MCWPXOoMCOqYnvZgQICwVixA6Fiz6p77CSKWnl4j41VTRTzbA+tV XUigCR3NTYj9iX6D/5k1XS4ZNfhcf7xrJ4ZfCkp8AJJlzX+2OVTat7XbnqhkFQnMiO7xIQnM DIs1McOa1ImgzsV0WUhTeo5AX6yjYp7BbZuCylqF/uu9bwSj5/K+cpv/MgTjLj50AtvM5x3c twtgrz3fcnbmKj7VHAzuPFWB1wmk2/rWBKq59ps1VlXZYDc7gUlIQD/SpuYec9NRjn44MqGv QGNrCk2N9qdzqhHhfkl1gq6tmtUnMvJwyBU0gPt+eEugIm7UxR/g82wtcSkWwH8494Y55Y5/ 7cOqAtr71WSNQKBJgNS9spcI+SMCjgUBjMOGWdLRDOE7wGAWvEr9rS7K8u7O+nVZQUxPIJ6d r8eWIdkVR3V1PlCMWI0pEO2AvKWn+BUTPkzdwbz4Rlu5XnLYCbchGreRQLqY+Nsv8fCsrUV7 KYI5RNGcLuKmPoBMJgwxD+YZ9PMnMTOfdl+uoTaharmIbmO4fqvuvUfLL4P7z2CwspXWv5Hz 8tRz72CMJc7l26e3PxjRTLMkmdP3DXzNZVKuz37uITwI8COslnqQ4Ok2m04cmNNHljv8UNDQ 9DCYKitpn+iXi9/G7O4WksEAFaFFxp7LLpVG4PgQcLNkjzYIsSotn3QxEU4FK3YjtEC+/GGg 9WoFp6vYitKYaL+CwkA9W7dkWXkmUUv3DPa5sHgKWM6YPEd/oDf9cbcZ00MT+OOw1+mA5spm sGQhQDXFXjGjTnjrjgqocVCuHZf9xVmxyqPsZQlHLauSyn1IMSb0peewTrfd+cgA4oSTYRrE Z26bUjjL2JnivqFXEym90iMFpHaH2eBZVPCAjtXvQTppnbPCVLCUuajz2TjB8+Pk7n7V8biG DaISqIQv3TGVZGtndE0qHlzUNsegymDjBNQ0E/lbc4OXXNu3513+POXKa13meLQnYpw+0WMl j+EHEvCzIr4+ry+A+emT6EG3lj+44nOfbFCq8/N5vJ3Gm2FYGOnaYaPvNd8Zp/LuryuusTXe /3QX7NEBrIT8cSnyCFrHcsPyd57EQ+mfTzwRv/8SyW2mU8Dfe6GiUue5grZ/Wnq07qSPaD3M 8n0ZYbve6sPn7wbdDD46fNdDJHIg7Sp2nzb+xAk+EigYsC8J9IW7/cWn/08VsC+jMUBsL9jl kfT6R2+6qpAP4lQ+UiPwZiumM0n9GOJnYxugP4AuUCbUgg5kWrS++h0v7tk/4TGUWPqwv7BE mH/wBc9/nDWTGf1bRyMdNHHU1mLGw94m9l5uWMasn5DxirbfhK+DOBQzKAWY4YbKiOArMLqB lmp/mOgu+MbiL9nCTdpyFyLK4L02GpR6qJcU6xMN8N19yxIlKXhKS2pOa1kTfsUDO+L30iur ctTz1ZUu1zzh84jIM21SCuSqv45mId+mEunw1PpxrKwYip4GDSAEdcFxbW668mBQVuDg==
  • Ironport-sdr: Y7X9lGTq0oY4u7gtZSUeGxDUEEXLmq1XtX/WkJYhOy2NtZrve5R8JL4HZMr0Sbo1gIBZpmWsoD gs7VnjhvPFoqtrsUCOM4HJKoDyZpzLbuP/7t87W+WJHgwNU3B1ooQ95NfChQy4Lk7L4u08+4LH Ni9GruKmriWYWLGZtLMNfNKlzhqXKsQr7QL6HaL/0UH4m1TOWMt3bPTMq/zNYJo+SA2yKkNhUe NDgKCgsMC5PN/KAr42tFEYugh5ENtJL/9IABqbBRtqqIHor8ll5EnGr9e5vpLL1CKRG0zOaDFN wYU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Apr 19, 2021 at 02:29:38PM +0200, Jan Beulich wrote:
> On 19.04.2021 14:09, Roger Pau Monné wrote:
> > On Mon, Apr 19, 2021 at 01:46:02PM +0200, Jan Beulich wrote:
> >> On 19.04.2021 11:16, Roger Pau Monné wrote:
> >>> Adding Paul also for the Viridian part.
> >>>
> >>> On Fri, Apr 16, 2021 at 03:16:41PM +0200, Jan Beulich wrote:
> >>>> Zapping leaf data for out of range leaves is just one half of it: To
> >>>> avoid guests (bogusly or worse) inferring information from mere leaf
> >>>> presence, also shrink maximum indicators such that the respective
> >>>> trailing entry is not all blank (unless of course it's the initial
> >>>> subleaf of a leaf that's not the final one).
> >>>>
> >>>> This is also in preparation of bumping the maximum basic leaf we
> >>>> support, to ensure guests not getting exposed related features won't
> >>>> observe a change in behavior.
> >>>>
> >>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>>> ---
> >>>> v3: Record the actual non-empty subleaf in p->basic.raw[0x7], rather
> >>>>     than subleaf 0. Re-base over Viridian leaf 40000005 addition.
> >>>> v2: New.
> >>>>
> >>>> --- a/tools/tests/cpu-policy/test-cpu-policy.c
> >>>> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
> >>>> @@ -8,10 +8,13 @@
> >>>>  #include <err.h>
> >>>>  
> >>>>  #include <xen-tools/libs.h>
> >>>> +#include <xen/asm/x86-defns.h>
> >>>>  #include <xen/asm/x86-vendors.h>
> >>>>  #include <xen/lib/x86/cpu-policy.h>
> >>>>  #include <xen/domctl.h>
> >>>>  
> >>>> +#define XSTATE_FP_SSE  (X86_XCR0_FP | X86_XCR0_SSE)
> >>>> +
> >>>>  static unsigned int nr_failures;
> >>>>  #define fail(fmt, ...)                          \
> >>>>  ({                                              \
> >>>> @@ -553,6 +556,103 @@ static void test_cpuid_out_of_range_clea
> >>>>      }
> >>>>  }
> >>>>  
> >>>> +static void test_cpuid_maximum_leaf_shrinking(void)
> >>>> +{
> >>>> +    static const struct test {
> >>>> +        const char *name;
> >>>> +        struct cpuid_policy p;
> >>>> +    } tests[] = {
> >>>> +        {
> >>>> +            .name = "basic",
> >>>> +            .p = {
> >>>> +                /* Very basic information only. */
> >>>> +                .basic.max_leaf = 1,
> >>>> +                .basic.raw_fms = 0xc2,
> >>>> +            },
> >>>> +        },
> >>>> +        {
> >>>> +            .name = "cache",
> >>>> +            .p = {
> >>>> +                /* Cache subleaves present. */
> >>>> +                .basic.max_leaf = 4,
> >>>> +                .cache.subleaf[0].type = 1,
> >>>
> >>> On a private conversation with Andrew he raised the issue that the
> >>> shrinking might be overly simplistic. For example if the x2APIC
> >>> feature bit in leaf 1 is set then the max leaf should be at least 0xb
> >>> in order to be able to fetch the x2APIC ID, even if it's 0.
> >>
> >> But in such a case the "type" field of leaf 0xb's first sub-leaf is
> >> going to be non-zero, isn't it?
> > 
> > Right, as type 0 is invalid according to Intel SDM, so you will never
> > be able to shrink below 0xb while having x2APIC set.
> > 
> > I still wonder however if there's any other such dependency, where
> > shrinking the max cpuid leaf could force us to drop features exposed
> > in inferior leaves.
> 
> My take is that, just like for the x2APIC case, such leaves won't be
> all blank if the qualifying bit is set. Or if one ends up being all
> blank, a bug likely sits elsewhere.

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

I'm not able to spot any more dependencies ATM, so worse case we
discover some of those along the way and add the missing logic if
required, in any case seems like a fine starting point.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.