All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "George Dunlap" <george.dunlap@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 11/17] x86/CPUID: adjust extended leaves out of range clearing
Date: Thu, 15 Apr 2021 15:56:46 +0200	[thread overview]
Message-ID: <2cca15ba-b704-c038-5b3d-63435d3c6e80@suse.com> (raw)
In-Reply-To: <b8960b03-4671-8653-2897-7d1b116e599b@citrix.com>

On 15.04.2021 14:48, Andrew Cooper wrote:
> On 23/11/2020 14:32, Jan Beulich wrote:
>> --- a/xen/lib/x86/cpuid.c
>> +++ b/xen/lib/x86/cpuid.c
>> @@ -232,7 +232,9 @@ void x86_cpuid_policy_clear_out_of_range
>>                      ARRAY_SIZE(p->xstate.raw) - 1);
>>      }
>>  
>> -    zero_leaves(p->extd.raw, (p->extd.max_leaf & 0xffff) + 1,
>> +    zero_leaves(p->extd.raw,
>> +                ((p->extd.max_leaf >> 16) == 0x8000
>> +                 ? (p->extd.max_leaf & 0xffff) + 1 : 0),
>>                  ARRAY_SIZE(p->extd.raw) - 1);
> 
> Honestly, this is unnecessary complexity and overhead, and the logic is
> already hard enough to follow.
> 
> There won't be extd.max_leaf with the high half != 0x8000 in real
> policies, because of how we fill them.  Nor ought there to be, given the
> intended meaning of this part of the union.
> 
> I think we simply forbid this case, rather than taking extra complexity
> to cope with it.  Approximately all VMs will have 0x80000008 as a
> minimum, and I don't think catering to pre-64bit Intel CPUs is worth our
> effort either.

"Forbid" has got to mean something other than "assume all input is fine".
Aiui guest config files can restrict the maximum sub-leaves exposed to a
guest. If we don't want to handle the case here, where else to you
suggest we at least and complain about the broken assumption? (IOW I'd
be okay dropping this patch if your "forbid" actually means some
enforcement elsewhere, and then perhaps a comment pointing there ahead
of the zero_leaves() invocation here.)

Jan


  reply	other threads:[~2021-04-15 13:56 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 14:21 [PATCH v2 00/17] xvmalloc() / x86 xstate area / x86 CPUID / AMX beginnings Jan Beulich
2020-11-23 14:23 ` [PATCH v2 01/17] mm: check for truncation in vmalloc_type() Jan Beulich
2020-11-25 12:00   ` Julien Grall
2020-11-23 14:23 ` [PATCH v2 02/17] mm: introduce xvmalloc() et al and use for grant table allocations Jan Beulich
2020-11-25 12:15   ` Julien Grall
2020-11-25 12:57     ` Jan Beulich
2020-11-25 19:48       ` Stefano Stabellini
2020-11-26 11:34         ` Jan Beulich
2020-11-26 13:22           ` Julien Grall
2020-11-26 15:18             ` Jan Beulich
2020-11-26 15:53               ` Julien Grall
2020-11-26 17:03                 ` Jan Beulich
2020-11-23 14:27 ` [PATCH v2 03/17] x86/xstate: use xvzalloc() for save area allocation Jan Beulich
2020-11-23 14:28 ` [PATCH v2 04/17] x86/xstate: re-size save area when CPUID policy changes Jan Beulich
2020-11-23 14:28 ` [PATCH v2 05/17] x86/xstate: re-use valid_xcr0() for boot-time checks Jan Beulich
2020-11-23 14:29 ` [PATCH v2 06/17] x86/xstate: drop xstate_offsets[] and xstate_sizes[] Jan Beulich
2020-11-23 14:30 ` [PATCH v2 07/17] x86/xstate: replace xsave_cntxt_size and drop XCNTXT_MASK Jan Beulich
2020-11-23 14:30 ` [PATCH v2 08/17] x86/xstate: avoid accounting for unsupported components Jan Beulich
2020-11-23 14:31 ` [PATCH v2 09/17] x86: use xvmalloc() for extended context buffer allocations Jan Beulich
2020-11-23 14:32 ` [PATCH v2 10/17] x86/xstate: enable AMX components Jan Beulich
2020-11-23 14:32 ` [PATCH v2 11/17] x86/CPUID: adjust extended leaves out of range clearing Jan Beulich
2021-02-11 15:40   ` Ping: " Jan Beulich
2021-04-15 12:33   ` Roger Pau Monné
2021-04-15 12:48   ` Andrew Cooper
2021-04-15 13:56     ` Jan Beulich [this message]
2020-11-23 14:33 ` [PATCH v2 12/17] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents Jan Beulich
2021-02-11 15:42   ` Jan Beulich
2021-04-15  9:52   ` Roger Pau Monné
2021-04-15 10:37     ` Jan Beulich
2021-04-15 12:30       ` Roger Pau Monné
2021-04-15 14:10         ` Jan Beulich
2020-11-23 14:33 ` [PATCH v2 13/17] x86/CPUID: move bounding of max_{,sub}leaf fields to library code Jan Beulich
2020-11-23 14:34 ` [PATCH v2 14/17] x86/CPUID: enable AMX leaves Jan Beulich
2020-11-23 14:35 ` [PATCH v2 15/17] x86emul: introduce X86EMUL_FPU_tile Jan Beulich
2020-11-23 14:36 ` [PATCH v2 16/17] x86emul: support TILERELEASE Jan Beulich
2020-11-23 14:37 ` [PATCH v2 17/17] x86emul: support {LD,ST}TILECFG Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cca15ba-b704-c038-5b3d-63435d3c6e80@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.