qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@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 12:46:21 +0100	[thread overview]
Message-ID: <20170505114621.GG12773@redhat.com> (raw)
In-Reply-To: <20170504184241.GB3482@thinpad.lan.raisama.net>

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.

Having a separate variable just for TCG seems the only viable option
to me - eg

    DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  parent reply	other threads:[~2017-05-05 11: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 [this message]
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=20170505114621.GG12773@redhat.com \
    --to=berrange@redhat.com \
    --cc=ehabkost@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).