All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	"Richard W.M. Jones" <rjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf
Date: Thu, 4 May 2017 15:42:41 -0300	[thread overview]
Message-ID: <20170504184241.GB3482@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20170504145658.5506-1-berrange@redhat.com>

On Thu, May 04, 2017 at 03:56:58PM +0100, Daniel P. Berrange wrote:
> Currently when running KVM, we expose "KVMKVMKVM\0\0\0" in
> the 0x40000000 CPUID leaf. Other hypervisors (VMWare,
> HyperV, Xen, BHyve) all do the same thing, which leaves
> TCG as the odd one out.
> 
> The CPUID is used by software to detect when running in a
> virtual environment and change behaviour in certain ways.
> For example, systemd supports a ConditionVirtualization=
> setting in unit files. Currently they have to resort to
> custom hacks like looking for 'fw-cfg' entry in the
> /proc/device-tree file. The virt-what command has the
> same hacks & needs.
> 
> This change thus proposes a signature TCGTCGTCGTCG to be
> reported when running under TCG.
> 
> NB1, for reasons I don't undersatnd 'cpu_x86_cpuid' function
> clamps the requested CPUID leaf based on env->cpuid_level.

That's how CPUID is specified: Intel SDM says: "If a value
entered for CPUID.EAX is higher than the maximum input value for
basic or extended function for that processor then the data for
the highest basic information leaf is returned."

> The latter comes from the CPU model definitions, and is
> lower than 0x40000000, so the CPUID signature request just
> gets turned into a completely different request. eg when
> using '-cpu qemu64', the 0x40000000 request from the guest
> gets clamped to 0xD and thus returns totally bogus data.
> I just removed the clamping code, but someone who understands
> this might have a better suggestion.
> 

I would rewrite that code as:

    switch (index & 0xF0000000) {
    case 0:
        [...] // check cpuid_level
    case 0x40000000:
        if (index > 0x40000001) {
            /* Not sure what we should do here. Intel and KVM
             * documentation is not explicit about it, but it
             * looks like KVM will return the highest _basic_
             * leaf (env->cpuid_level) on that case.
             */
            index = env->cpuid_level;
        }
        [...]
    case 0x80000000:
        [...] // check cpuid_xlevel
    case 0xC0000000:
        [...] // check cpuid_xlevel2
    default:
       /* Intel documentation states that invalid EAX input will
        * return the same information as EAX=cpuid_level
        * (Intel SDM Vol. 2A - Instruction Set Reference - CPUID)
        */
        index = env->cpuid_level;
    }

> NB2, for KVM, we added a flag for '-cpu kvm=off' to let you
> hide the KVMKVMKVM signature from guests. Presumably we should
> add a 'tcg=off' flag for the same reason ?

I don't like "kvm=off" because it sounds like it disables KVM
completely. "tcg=off" would be misleading as well.

What about a generic "hypervisor-cpuid=off" property?

> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>  target/i386/cpu.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 13c0985..ac2776e 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2626,6 +2626,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>      X86CPU *cpu = x86_env_get_cpu(env);
>      CPUState *cs = CPU(cpu);
>      uint32_t pkg_offset;
> +    uint32_t signature[3];
>  
>      /* test if maximum index reached */
>      if (index & 0x80000000) {
> @@ -2646,8 +2647,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>              }
>          }
>      } else {
> -        if (index > env->cpuid_level)
> +        /* XXX this just breaks CPUID turning guest requests
> +         * into something totally different, thus returning
> +         * garbage data
> +         */
> +        if (0 && index > env->cpuid_level) {
>              index = env->cpuid_level;
> +        }
>      }
>  
>      switch(index) {
> @@ -2872,6 +2878,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>          }
>          break;
>      }
> +    case 0x40000000:
> +        /* XXX add flag to let us hide this */
> +        memcpy(signature, "TCGTCGTCGTCG", 12);

This shouldn't be seen by any guests if not using TCG. Probably
that will never happen with the current code, but I would make
this conditional on tcg_enabled() just in case.

Note that the CPUID code at kvm_arch_init_vcpu() will ignore the
values here. Probably worth mentioning that in a comment so
people don't get confused.

> +        *eax = 0x40000001;

Should we really return 0x40000001 here, if we still don't have
anything being returned on CPUID[0x40000001]?

If we really want to return 0x40000001 here, an explicit
"case 0x40000001:" line returning all-zeroes would make that
intention clearer.

> +        *ebx = signature[0];
> +        *ecx = signature[1];
> +        *edx = signature[2];
> +        break;
>      case 0x80000000:
>          *eax = env->cpuid_xlevel;
>          *ebx = env->cpuid_vendor1;
> -- 
> 2.9.3
> 

-- 
Eduardo

  reply	other threads:[~2017-05-04 18:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 14:56 [Qemu-devel] [PATCH RFC] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf Daniel P. Berrange
2017-05-04 18:42 ` Eduardo Habkost [this message]
2017-05-05  7:45   ` Paolo Bonzini
2017-05-05 11:46   ` Daniel P. Berrange
2017-05-05 16:46     ` Eduardo Habkost

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=20170504184241.GB3482@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=rth@twiddle.net \
    /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.