All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: keir@xen.org, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jun.nakajima@intel.com, andrew.cooper3@citrix.com,
	yang.z.zhang@intel.com
Subject: Re: [PATCH v5 1/4] xen/libxc: Allow changes to hypervisor CPUID leaf from config file
Date: Wed, 19 Mar 2014 09:27:00 +0000	[thread overview]
Message-ID: <1395221220.10203.8.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <1395190714-3802-2-git-send-email-boris.ostrovsky@oracle.com>

On Tue, 2014-03-18 at 20:58 -0400, Boris Ostrovsky wrote:
> Currently only "real" cpuid leaves can be overwritten by users via
> 'cpuid' option in the configuration file. This patch provides ability to
> do the same for hypervisor leaves (but for now only 0x40000000 is allowed).
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  tools/libxc/xc_cpuid_x86.c   |   71 ++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/domain.c        |   19 +++++++++--
>  xen/arch/x86/traps.c         |    3 ++
>  xen/include/asm-x86/domain.h |    7 +++++
>  4 files changed, 95 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index bbbf9b8..5501d5b 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -33,6 +33,8 @@
>  #define DEF_MAX_INTELEXT  0x80000008u
>  #define DEF_MAX_AMDEXT    0x8000001cu
>  
> +#define IS_HYPERVISOR_LEAF(idx) (((idx) & 0xffff0000) == 0x40000000)

Not idx == 0x40000000?

Also as I think Jan said before if viridian support is enabled then the
Xen leaves may be elsewhere (at 0x100 increments above that address
IIRC).

> +
>  static int hypervisor_is_64bit(xc_interface *xch)
>  {
>      xen_capabilities_info_t xen_caps = "";
> @@ -43,22 +45,31 @@ static int hypervisor_is_64bit(xc_interface *xch)
>  static void cpuid(const unsigned int *input, unsigned int *regs)
>  {
>      unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1];
> +    uint8_t is_hyp = IS_HYPERVISOR_LEAF(input[0]);
>  #ifdef __i386__
>      /* Use the stack to avoid reg constraint failures with some gcc flags */
>      asm (
>          "push %%ebx; push %%edx\n\t"
> +        "testb $0xff,%5\n\t"
> +        "jz .Lcpuid%=\n\t"
> +        XEN_EMULATE_PREFIX
> +        ".Lcpuid%=:\n\t"
>          "cpuid\n\t"
>          "mov %%ebx,4(%4)\n\t"
>          "mov %%edx,12(%4)\n\t"
>          "pop %%edx; pop %%ebx\n\t"
>          : "=a" (regs[0]), "=c" (regs[2])
> -        : "0" (input[0]), "1" (count), "S" (regs)
> +        : "0" (input[0]), "1" (count), "S" (regs), "q" (is_hyp)

I think this would be clearer refactored into make_real_cpuid() and
make_pv_cpuid() functions.

It also seems strange to use emulated for a subset of leafs, although I
understand why.

How does this play out in e.g. a PVH toolstack domain where the even
"real" cpuid might be faked?

Perhaps we should have a hypercall to retrieve the complete set of real
h/w, levelled h/w, pv, emulated etc values for a given leaf?

> @@ -726,6 +740,57 @@ int xc_cpuid_check(
>      return rc;
>  }
>  
> +static void xc_cpuid_revert(unsigned int *reg, unsigned int polreg,
> +    unsigned int start, unsigned int end, char *config)
[...]
> +static void xc_cpuid_constrain(const unsigned int *input, unsigned int *regs,
> +    unsigned int *polregs, char **config_transformed)

These complicated functions most certainly need some sort of explanation
about what they are trying to do.

Why do the hypervisor leaves need to be manipulated by new functions, do
the existing facilities used for all the others not work?

> +{
> +    unsigned int i;
> +
> +    if ( IS_HYPERVISOR_LEAF(input[0]) )
> +    {
> +        switch ( input[0] & 0xff )
> +        {
> +            case 0:
> +                if ( (regs[0] & 0xffffff00) != (polregs[0] & 0xffffff00) )
> +                        xc_cpuid_revert(&regs[0], polregs[0], 8, 31,
> +                                        config_transformed[0]);
> +                if ( (regs[0] & 0xff) < 2 )

Lots of magic numbers with varying number's of f's. Please #define them.

> +                        xc_cpuid_revert(&regs[0], polregs[0], 0, 7,
> +                                        config_transformed[0]);
> +                for (i = 1; i < 4; i++)
> +                    if ( regs[i] != polregs[i] )
> +                        xc_cpuid_revert(&regs[i], polregs[i], 0, 31,
> +                                        config_transformed[i]);
> +                break;
> +
> +            default:
> +                for (i = 0; i < 4; i++)
> +                    xc_cpuid_revert(&regs[i], polregs[i], 0, 31,
> +                                    config_transformed[i]);
> +                break;
> +        }
> +    }
> +}
> +
>  /*
>   * Configure a single input with the informatiom from config.
>   *

  parent reply	other threads:[~2014-03-19  9:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19  0:58 [PATCH v5 0/4] Expose HW APIC virtualization support to HVM guests Boris Ostrovsky
2014-03-19  0:58 ` [PATCH v5 1/4] xen/libxc: Allow changes to hypervisor CPUID leaf from config file Boris Ostrovsky
2014-03-19  9:26   ` Jan Beulich
2014-03-19  9:29     ` Ian Campbell
2014-03-19 14:26       ` Boris Ostrovsky
2014-03-19  9:27   ` Ian Campbell [this message]
2014-03-19  9:32     ` Jan Beulich
2014-03-19  9:52       ` Ian Campbell
2014-03-19 10:06         ` Jan Beulich
2014-03-19 10:39           ` Ian Campbell
2014-03-19 11:44             ` Jan Beulich
2014-03-19 12:02               ` Ian Campbell
2014-03-19 14:41     ` Boris Ostrovsky
2014-03-20  9:25       ` Ian Campbell
2014-03-20 13:50         ` Boris Ostrovsky
2014-03-19  0:58 ` [PATCH v5 2/4] x86/hvm: Revert 80ecb40362365ba77e68fc609de8bd3b7208ae19 Boris Ostrovsky
2014-03-19  0:58 ` [PATCH v5 3/4] x86/hvm: Add HVM-specific hypervisor CPUID leaf Boris Ostrovsky
2014-03-19  0:58 ` [PATCH v5 4/4] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests Boris Ostrovsky

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=1395221220.10203.8.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@intel.com \
    /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.