All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/10] x86/gen-cpuid: Create max and default variations of INIT_*_FEATURES
Date: Thu, 27 Feb 2020 11:34:02 +0100	[thread overview]
Message-ID: <a61466c5-14a0-da25-62cf-72c23a0ac8e0@suse.com> (raw)
In-Reply-To: <2e0267e6-d2e3-324e-1e4d-512e172967cd@citrix.com>

On 27.02.2020 11:29, Andrew Cooper wrote:
> On 27/02/2020 08:02, Jan Beulich wrote:
>> On 26.02.2020 21:22, Andrew Cooper wrote:
>>> For now, write the same content for both.  Update the users of the
>>> initialisers to use the new name, and extend xen-cpuid to dump both default
>>> and max featuresets.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Hypervisor and libxc parts
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Which other bit are you concerned with?  xen-cpuid.c is explicitly under
> x86 maintainership.
> 
>>
>>> --- a/tools/misc/xen-cpuid.c
>>> +++ b/tools/misc/xen-cpuid.c
>>> @@ -283,12 +283,18 @@ static void dump_info(xc_interface *xch, bool detail)
>>>                        nr_features, "Known", detail);
>>>      decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_SPECIAL),
>>>                        nr_features, "Special", detail);
>>> -    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_PV),
>>> -                      nr_features, "PV Mask", detail);
>>> -    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_SHADOW),
>>> -                      nr_features, "HVM Shadow Mask", detail);
>>> -    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_HAP),
>>> -                      nr_features, "HVM Hap Mask", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_PV_MAX),
>>> +                      nr_features, "PV Max", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_PV_DEF),
>>> +                      nr_features, "PV Default", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_SHADOW_MAX),
>>> +                      nr_features, "HVM Shadow Max", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_SHADOW_DEF),
>>> +                      nr_features, "HVM Shadow Default", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_HAP_MAX),
>>> +                      nr_features, "HVM Hap Max", detail);
>>> +    decode_featureset(xc_get_static_cpu_featuremask(XC_FEATUREMASK_HVM_HAP_DEF),
>>> +                      nr_features, "HVM Hap Default", detail);
>> Spotting differences between max and default this way is, I assume,
>> going to be quite difficult / error prone.
> 
> Not any more or less than between other similar sets (most obviously,
> hap and shadow, but raw and host also tend to fairly similar).

Well, yes, but it may matter more for the (def,max) pairs.

>> Wouldn't it be better to
>> produce the default set in full, and then list just the extra items
>> in max?
> 
> I don't see how that would work.  The sets are either rendered as a hex
> bitmap (so spotting a different is fairly easy), or tabulated with
> feature names subdivided by word.

For the hex printing I agree it's fine this way. For the tabulated
printing, why not simply mask out all "default" bits from "max"
before producing the output, adjusting the headline accordingly?

>> Aiui max is always going to be a superset of def.
> 
> It is.  I did consider distinguishing using lower and upper case, which
> is about the only way I can think of sensibly merging the two sets together.
> 
> However, this is a pain to do in C, and it would result in the set being
> rendered differently depending on whether it was a static set, or a
> user-provided one.  It would also result in the case being inverted
> compared to the annotation character.
> 
> For now, I'm honestly not sure that it matters too much.  I'm probably
> going to give xen-cpuid an overhaul anyway (perhaps into python) to be a
> more useful calculator for policy settings.

Oh, okay. In that case perhaps indeed not worth to spend too much
effort here anymore.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-02-27 10:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 20:22 [Xen-devel] [PATCH 00/10] x86: Default vs Max policies Andrew Cooper
2020-02-26 20:22 ` [Xen-devel] [PATCH 01/10] x86/sysctl: Don't return cpu policy data for compiled-out support (2) Andrew Cooper
2020-02-27  7:38   ` Jan Beulich
2020-02-27  9:33     ` Andrew Cooper
2020-02-27  9:40       ` Jan Beulich
2020-02-27 16:24         ` Andrew Cooper
2020-02-26 20:22 ` [Xen-devel] [PATCH 02/10] tools/libxc: Simplify xc_get_static_cpu_featuremask() Andrew Cooper
2020-02-27  7:47   ` Jan Beulich
2020-02-27  9:55     ` Andrew Cooper
2020-02-27 16:27       ` Andrew Cooper
2020-02-26 20:22 ` [Xen-devel] [PATCH 03/10] x86/gen-cpuid: Rework internal logic to ease future changes Andrew Cooper
2020-02-27  7:57   ` Jan Beulich
2020-02-27 10:08     ` Andrew Cooper
2020-02-26 20:22 ` [Xen-devel] [PATCH 04/10] x86/gen-cpuid: Create max and default variations of INIT_*_FEATURES Andrew Cooper
2020-02-27  8:02   ` Jan Beulich
2020-02-27 10:29     ` Andrew Cooper
2020-02-27 10:34       ` Jan Beulich [this message]
2020-02-26 20:22 ` [Xen-devel] [PATCH 05/10] x86/msr: Compile out unused logic/objects Andrew Cooper
2020-02-27  8:07   ` Jan Beulich
2020-02-27 10:37     ` Andrew Cooper
2020-02-27 11:24       ` Jan Beulich
2020-02-26 20:22 ` [Xen-devel] [PATCH 06/10] x86/msr: Introduce and use default MSR policies Andrew Cooper
2020-02-27  8:11   ` Jan Beulich
2020-02-26 20:22 ` [Xen-devel] [PATCH 07/10] x86/cpuid: Compile out unused logic/objects Andrew Cooper
2020-02-27  8:12   ` Jan Beulich
2020-02-26 20:22 ` [Xen-devel] [PATCH 08/10] x86/cpuid: Introduce and use default CPUID policies Andrew Cooper
2020-02-27  8:19   ` Jan Beulich
2020-02-27 10:55     ` Andrew Cooper
2020-02-27 11:29       ` Jan Beulich
2020-02-26 20:22 ` [Xen-devel] [PATCH 09/10] x86/gen-cpuid: Distinguish default vs max in feature annotations Andrew Cooper
2020-02-27  8:21   ` Jan Beulich
2020-02-26 20:22 ` [Xen-devel] [PATCH 10/10] x86/hvm: Do not enable MPX by default Andrew Cooper
2020-02-27  8:23   ` 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=a61466c5-14a0-da25-62cf-72c23a0ac8e0@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@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.