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: Fri, 5 May 2017 13:46:12 -0300	[thread overview]
Message-ID: <20170505164612.GE3482@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20170505114621.GG12773@redhat.com>

On Fri, May 05, 2017 at 12:46:21PM +0100, Daniel P. Berrange wrote:
> On Thu, May 04, 2017 at 03:42:41PM -0300, Eduardo Habkost wrote:
> > 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.
> 
> [snip]
> 
> > > 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?
> 
> Assuming that is intended to obsolete the existing 'kvm' parameter too,
> I'm not seeing a way to introduce that in a backwards compatible safe
> manner.
> 
> eg we add
> 
>     DEFINE_PROP_BOOL("hypervisor-cpuid", X86CPU, expose_hypervisor, true),
> 
> and in legacy machine types we need to set
> 
>     {\
>         .driver   = TYPE_X86_CPU,\
>         .property = "hypervisor-cpuid",\
>         .value    = "off",\
>     },\
> 
> to prevent TCGTCGTCGTCG appearing.
> 
> 
> Now in current KVM code we have
> 
>     if (cpu->expose_kvm) {
>         memcpy(signature, "KVMKVMKVM\0\0\0", 12);
>         ....
>     }
> 
> if we add 'expose_hypervisor' as a generic variable and thus change
> existing KVM code to
> 
>     if (cpu->expose_kvm || cpu->expose_hypervisor)
> 
> then to disable the KVMKVMKVMKVM signature, we now need to set *two*
> flags - kvm=off, and hypervisor-cpuid=off and this will break existing
> apps that are only setting kvm=off to disable it.
> 
> Conversely if we do
> 
>     if (cpu->expose_kvm && cpu->expose_hypervisor)
> 
> we're going to break KVMKVMKVM signature reporting by default, since
> we need to set hypervisor-cpuid=off in back compat machine types
> to prevent TCGTCGTCGTCG being exposed.
> 
> So it seems we're doomed either way, as we can't distinguish between
> a boolean value that is at its default, vs a boolean value that has
> been explicitly set to a value that matches the default.

That's true, even if we add a hypervisor-cpuid property, we need
a way to represent the behavior of QEMU 2.9 (disabling hypervisor
CPUID only for TCG).

> 
> Having a separate variable just for TCG seems the only viable option
> to me - eg
> 
>     DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),

Sounds good to me.

-- 
Eduardo

      reply	other threads:[~2017-05-05 16:46 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
2017-05-05  7:45   ` Paolo Bonzini
2017-05-05 11:46   ` Daniel P. Berrange
2017-05-05 16:46     ` Eduardo Habkost [this message]

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=20170505164612.GE3482@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.