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.xen.org>
Subject: Re: [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets
Date: Mon, 15 Feb 2016 06:37:58 -0700	[thread overview]
Message-ID: <56C1E2C602000078000D2231@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1454679743-18133-12-git-send-email-andrew.cooper3@citrix.com>

>>> On 05.02.16 at 14:42, <andrew.cooper3@citrix.com> wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -1,13 +1,165 @@
>  #include <xen/lib.h>
>  #include <asm/cpuid.h>
> +#include <asm/hvm/hvm.h>
> +#include <asm/hvm/vmx/vmcs.h>
> +#include <asm/processor.h>
> +
> +#define COMMON_1D INIT_COMMON_FEATURES
>  
>  const uint32_t known_features[] = INIT_KNOWN_FEATURES;
>  const uint32_t inverted_features[] = INIT_INVERTED_FEATURES;
>  
> +static const uint32_t pv_featuremask[] = INIT_PV_FEATURES;
> +static const uint32_t hvm_shadow_featuremask[] = INIT_HVM_SHADOW_FEATURES;
> +static const uint32_t hvm_hap_featuremask[] = INIT_HVM_HAP_FEATURES;

Considering that calculate_featuresets() gets called from
__start_xen(), that function and some others as well as the
above could apparently all live in .init.* sections.

> +uint32_t __read_mostly raw_featureset[FSCAPINTS];
> +uint32_t __read_mostly host_featureset[FSCAPINTS];
> +uint32_t __read_mostly pv_featureset[FSCAPINTS];
> +uint32_t __read_mostly hvm_featureset[FSCAPINTS];
> +
> +static void sanitise_featureset(uint32_t *fs)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < FSCAPINTS; ++i )
> +    {
> +        /* Clamp to known mask. */
> +        fs[i] &= known_features[i];
> +    }
> +
> +    switch ( boot_cpu_data.x86_vendor )
> +    {
> +    case X86_VENDOR_INTEL:
> +        /* Intel clears the common bits in e1d. */
> +        fs[FEATURESET_e1d] &= ~COMMON_1D;
> +        break;
> +
> +    case X86_VENDOR_AMD:
> +        /* AMD duplicates the common bits between 1d and e1d. */
> +        fs[FEATURESET_e1d] = ((fs[FEATURESET_1d]  &  COMMON_1D) |
> +                              (fs[FEATURESET_e1d] & ~COMMON_1D));
> +        break;
> +    }

How is this meant to work with cross vendor migration?

> +static void calculate_raw_featureset(void)
> +{
> +    unsigned int i, max, tmp;
> +
> +    max = cpuid_eax(0);
> +
> +    if ( max >= 1 )
> +        cpuid(0x1, &tmp, &tmp,
> +              &raw_featureset[FEATURESET_1c],
> +              &raw_featureset[FEATURESET_1d]);
> +    if ( max >= 7 )
> +        cpuid_count(0x7, 0, &tmp,
> +                    &raw_featureset[FEATURESET_7b0],
> +                    &raw_featureset[FEATURESET_7c0],
> +                    &tmp);
> +    if ( max >= 0xd )
> +        cpuid_count(0xd, 1,
> +                    &raw_featureset[FEATURESET_Da1],
> +                    &tmp, &tmp, &tmp);
> +
> +    max = cpuid_eax(0x80000000);
> +    if ( max >= 0x80000001 )

I don't recall where it was that I recently stumbled across a similar
check, but this is dangerous: Instead of >= this should check that
the upper 16 bits equal 0x8000 and the lower ones are >= 1.

> +static void calculate_host_featureset(void)
> +{
> +    memcpy(host_featureset, boot_cpu_data.x86_capability,
> +           sizeof(host_featureset));
> +}

Why not simply

#define host_featureset boot_cpu_data.x86_capability

?

> +static void calculate_pv_featureset(void)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < ARRAY_SIZE(pv_featureset); ++i )
> +        pv_featureset[i] = host_featureset[i] & pv_featuremask[i];

I think when two arrays are involved simply using FSCAPINTS
as the upper bound would be more appropriate (and shorter).

> +static void calculate_hvm_featureset(void)
> +{
> +    unsigned int i;
> +    const uint32_t *hvm_featuremask;
> +
> +    if ( !hvm_enabled )
> +        return;
> +
> +    hvm_featuremask = hvm_funcs.hap_supported ?
> +        hvm_hap_featuremask : hvm_shadow_featuremask;
> +
> +    for ( i = 0; i < ARRAY_SIZE(hvm_featureset); ++i )
> +        hvm_featureset[i] = host_featureset[i] & hvm_featuremask[i];
> +
> +    /* Unconditionally claim to be able to set the hypervisor bit. */
> +    __set_bit(X86_FEATURE_HYPERVISOR, hvm_featureset);
> +
> +    /*
> +     * On AMD, PV guests are entirely unable to use 'sysenter' as Xen runs in
> +     * long mode (and init_amd() has cleared it out of host capabilities), but
> +     * HVM guests are able if running in protected mode.
> +     */
> +    if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> +         test_bit(X86_FEATURE_SEP, raw_featureset) )
> +        __set_bit(X86_FEATURE_SEP, hvm_featureset);
> +
> +    /*
> +     * With VT-x, some features are only supported by Xen if dedicated
> +     * hardware support is also available.
> +     */
> +    if ( cpu_has_vmx )
> +    {
> +        if ( !(vmx_vmexit_control & VM_EXIT_CLEAR_BNDCFGS) ||
> +             !(vmx_vmentry_control & VM_ENTRY_LOAD_BNDCFGS) )
> +            __clear_bit(X86_FEATURE_MPX, hvm_featureset);
> +
> +        if ( !cpu_has_vmx_xsaves )
> +            __clear_bit(X86_FEATURE_XSAVES, hvm_featureset);
> +
> +        if ( !cpu_has_vmx_pcommit )
> +            __clear_bit(X86_FEATURE_PCOMMIT, hvm_featureset);
> +    }
> +
> +    sanitise_featureset(pv_featureset);

s/pv_/hvm_/ ?

>  static void __maybe_unused build_assertions(void)

While affecting an earlier patch - __init?

> --- a/xen/include/asm-x86/cpuid.h
> +++ b/xen/include/asm-x86/cpuid.h
> @@ -5,12 +5,29 @@
>  
>  #define FSCAPINTS FEATURESET_NR_ENTRIES
>  
> +#define FEATURESET_1d     0 /* 0x00000001.edx      */
> +#define FEATURESET_1c     1 /* 0x00000001.ecx      */
> +#define FEATURESET_e1d    2 /* 0x80000001.edx      */
> +#define FEATURESET_e1c    3 /* 0x80000001.ecx      */
> +#define FEATURESET_Da1    4 /* 0x0000000d:1.eax    */
> +#define FEATURESET_7b0    5 /* 0x00000007:0.ebx    */
> +#define FEATURESET_7c0    6 /* 0x00000007:0.ecx    */
> +#define FEATURESET_e7d    7 /* 0x80000007.edx      */
> +#define FEATURESET_e8b    8 /* 0x80000008.ebx      */
> +
>  #ifndef __ASSEMBLY__
>  #include <xen/types.h>
>  
>  extern const uint32_t known_features[FSCAPINTS];
>  extern const uint32_t inverted_features[FSCAPINTS];
>  
> +extern uint32_t raw_featureset[FSCAPINTS];
> +extern uint32_t host_featureset[FSCAPINTS];
> +extern uint32_t pv_featureset[FSCAPINTS];
> +extern uint32_t hvm_featureset[FSCAPINTS];

I wonder whether it wouldn't be better to make these accessible
only via function calls, with the functions returning pointers to
const, to avoid seducing people into fiddling with these from
outside cpuid.c.

Jan

  reply	other threads:[~2016-02-15 13:37 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 13:41 [PATCH RFC v2 00/30] x86: Improvements to cpuid handling for guests Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 01/30] xen/x86: Drop X86_FEATURE_3DNOW_ALT Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 02/30] xen/x86: Do not store VIA/Cyrix/Centaur CPU features Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 03/30] xen/x86: Drop cpuinfo_x86.x86_power Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 04/30] xen/x86: Improvements to pv_cpuid() Andrew Cooper
2016-02-05 13:41 ` [PATCH v2 05/30] xen/public: Export cpu featureset information in the public API Andrew Cooper
2016-02-12 16:27   ` Jan Beulich
2016-02-17 13:08     ` Andrew Cooper
2016-02-17 13:34       ` Jan Beulich
2016-02-19 17:29   ` Joao Martins
2016-02-19 17:55     ` Andrew Cooper
2016-02-19 22:03       ` Joao Martins
2016-02-20 16:17         ` Andrew Cooper
2016-02-20 17:39           ` Joao Martins
2016-02-20 19:17             ` Andrew Cooper
2016-02-22 18:50               ` Joao Martins
2016-02-05 13:41 ` [PATCH v2 06/30] xen/x86: Script to automatically process featureset information Andrew Cooper
2016-02-12 16:36   ` Jan Beulich
2016-02-12 16:43     ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 07/30] xen/x86: Collect more cpuid feature leaves Andrew Cooper
2016-02-12 16:38   ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 08/30] xen/x86: Mask out unknown features from Xen's capabilities Andrew Cooper
2016-02-12 16:43   ` Jan Beulich
2016-02-12 16:48     ` Andrew Cooper
2016-02-12 17:14       ` Jan Beulich
2016-02-17 13:12         ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset Andrew Cooper
2016-02-12 16:47   ` Jan Beulich
2016-02-12 16:50     ` Andrew Cooper
2016-02-12 17:15       ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset Andrew Cooper
2016-02-12 17:05   ` Jan Beulich
2016-02-12 17:42     ` Andrew Cooper
2016-02-15  9:20       ` Jan Beulich
2016-02-15 14:38         ` Andrew Cooper
2016-02-15 14:50           ` Jan Beulich
2016-02-15 14:53             ` Andrew Cooper
2016-02-15 15:02               ` Jan Beulich
2016-02-15 15:41                 ` Andrew Cooper
2016-02-17 19:02                   ` Is: PVH dom0 - MWAIT detection logic to get deeper C-states exposed in ACPI AML code. Was:Re: " Konrad Rzeszutek Wilk
2016-02-17 19:58                     ` Boris Ostrovsky
2016-02-18 15:02                     ` Roger Pau Monné
2016-02-18 15:12                       ` Andrew Cooper
2016-02-18 16:24                         ` Boris Ostrovsky
2016-02-18 16:48                           ` Andrew Cooper
2016-02-18 17:03                         ` Roger Pau Monné
2016-02-18 22:08                           ` Konrad Rzeszutek Wilk
2016-02-18 15:16                       ` David Vrabel
2016-02-05 13:42 ` [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets Andrew Cooper
2016-02-15 13:37   ` Jan Beulich [this message]
2016-02-15 14:57     ` Andrew Cooper
2016-02-15 15:07       ` Jan Beulich
2016-02-15 15:52         ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 12/30] xen/x86: Generate deep dependencies of features Andrew Cooper
2016-02-15 14:06   ` Jan Beulich
2016-02-15 15:28     ` Andrew Cooper
2016-02-15 15:52       ` Jan Beulich
2016-02-15 16:09         ` Andrew Cooper
2016-02-15 16:27           ` Jan Beulich
2016-02-15 19:07             ` Andrew Cooper
2016-02-16  9:54               ` Jan Beulich
2016-02-17 10:25                 ` Andrew Cooper
2016-02-17 10:42                   ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 13/30] xen/x86: Clear dependent features when clearing a cpu cap Andrew Cooper
2016-02-15 14:53   ` Jan Beulich
2016-02-15 15:33     ` Andrew Cooper
2016-02-15 14:56   ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 14/30] xen/x86: Improve disabling of features which have dependencies Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 15/30] xen/x86: Improvements to in-hypervisor cpuid sanity checks Andrew Cooper
2016-02-15 15:43   ` Jan Beulich
2016-02-15 17:12     ` Andrew Cooper
2016-02-16 10:06       ` Jan Beulich
2016-02-17 10:43         ` Andrew Cooper
2016-02-17 10:55           ` Jan Beulich
2016-02-17 14:02             ` Andrew Cooper
2016-02-17 14:45               ` Jan Beulich
2016-02-18 12:17                 ` Andrew Cooper
2016-02-18 13:23                   ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 16/30] x86/cpu: Move set_cpumask() calls into c_early_init() Andrew Cooper
2016-02-16 14:10   ` Jan Beulich
2016-02-17 10:45     ` Andrew Cooper
2016-02-17 10:58       ` Jan Beulich
2016-02-18 12:41         ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 17/30] x86/cpu: Common infrastructure for levelling context switching Andrew Cooper
2016-02-16 14:15   ` Jan Beulich
2016-02-17  8:15     ` Jan Beulich
2016-02-17 10:46       ` Andrew Cooper
2016-02-17 19:06   ` Konrad Rzeszutek Wilk
2016-02-05 13:42 ` [PATCH v2 18/30] x86/cpu: Rework AMD masking MSR setup Andrew Cooper
2016-02-17  7:40   ` Jan Beulich
2016-02-17 10:56     ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 19/30] x86/cpu: Rework Intel masking/faulting setup Andrew Cooper
2016-02-17  7:57   ` Jan Beulich
2016-02-17 10:59     ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 20/30] x86/cpu: Context switch cpuid masks and faulting state in context_switch() Andrew Cooper
2016-02-17  8:06   ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 21/30] x86/pv: Provide custom cpumasks for PV domains Andrew Cooper
2016-02-17  8:13   ` Jan Beulich
2016-02-17 11:03     ` Andrew Cooper
2016-02-17 11:14       ` Jan Beulich
2016-02-18 12:48         ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 22/30] x86/domctl: Update PV domain cpumasks when setting cpuid policy Andrew Cooper
2016-02-17  8:22   ` Jan Beulich
2016-02-17 12:13     ` Andrew Cooper
2016-02-05 13:42 ` [PATCH v2 23/30] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL Andrew Cooper
2016-02-05 16:12   ` Wei Liu
2016-02-17  8:30   ` Jan Beulich
2016-02-17 12:17     ` Andrew Cooper
2016-02-17 12:23       ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers Andrew Cooper
2016-02-05 16:12   ` Wei Liu
2016-02-08 11:40     ` Andrew Cooper
2016-02-08 16:23   ` Tim Deegan
2016-02-08 16:36     ` Ian Campbell
2016-02-10 10:07       ` Andrew Cooper
2016-02-10 10:18         ` Ian Campbell
2016-02-18 13:37           ` Andrew Cooper
2016-02-17 20:06         ` Konrad Rzeszutek Wilk
2016-02-05 13:42 ` [PATCH v2 25/30] tools/libxc: Use public/featureset.h for cpuid policy generation Andrew Cooper
2016-02-05 16:12   ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 26/30] tools/libxc: Expose the automatically generated cpu featuremask information Andrew Cooper
2016-02-05 16:12   ` Wei Liu
2016-02-05 16:15     ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 27/30] tools: Utility for dealing with featuresets Andrew Cooper
2016-02-05 16:13   ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 28/30] tools/libxc: Wire a featureset through to cpuid policy logic Andrew Cooper
2016-02-05 16:13   ` Wei Liu
2016-02-05 13:42 ` [PATCH v2 29/30] tools/libxc: Use featuresets rather than guesswork Andrew Cooper
2016-02-05 16:13   ` Wei Liu
2016-02-17  8:55   ` Jan Beulich
2016-02-17 13:03     ` Andrew Cooper
2016-02-17 13:19       ` Jan Beulich
2016-02-05 13:42 ` [PATCH v2 30/30] tools/libxc: Calculate xstate cpuid leaf from guest information Andrew Cooper
2016-02-05 14:28   ` Jan Beulich
2016-02-05 15:22     ` Andrew Cooper
2016-02-08 17:26 ` [PATCH v2.5 31/30] Fix PV guest XSAVE handling with levelling Andrew Cooper
2016-02-17  9:02   ` Jan Beulich
2016-02-17 13:06     ` Andrew Cooper
2016-02-17 13:36       ` 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=56C1E2C602000078000D2231@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xen.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.