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>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf
Date: Tue, 9 May 2017 13:39:06 +0100 [thread overview]
Message-ID: <20170509123906.GG1669@redhat.com> (raw)
In-Reply-To: <20170509115228.GA3482@thinpad.lan.raisama.net>
On Tue, May 09, 2017 at 08:52:28AM -0300, Eduardo Habkost wrote:
> On Tue, May 09, 2017 at 12:20:34PM +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 signature is used by software to detect which
> > virtual environment they are running in and (potentially)
> > change behaviour in certain ways. For example, systemd
> > supports a ConditionVirtualization= setting in unit files.
> > The virt-what command can also report the virt type it is
> > running on
> >
> > Currently both these apps have to resort to custom hacks
> > like looking for 'fw-cfg' entry in the /proc/device-tree
> > file to identify TCG.
> >
> > This change thus proposes a signature "TCGTCGTCGTCG" to be
> > reported when running under TCG.
> >
> > To hide this, the -cpu option tcg-cpuid=off can be used.
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> > include/hw/i386/pc.h | 5 +++++
> > target/i386/cpu.c | 22 ++++++++++++++++++++++
> > target/i386/cpu.h | 1 +
> > 3 files changed, 28 insertions(+)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index f278b3a..3aec60f 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -376,6 +376,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
> > #define PC_COMPAT_2_8 \
> > HW_COMPAT_2_8 \
> > {\
> > + .driver = TYPE_X86_CPU,\
> > + .property = "tcg-cpuid",\
> > + .value = "off",\
> > + },\
> > + {\
> > .driver = "kvmclock",\
> > .property = "x-mach-use-reliable-get-clock",\
> > .value = "off",\
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 8cb4af4..ee4f515 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -2627,12 +2627,15 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> > CPUState *cs = CPU(cpu);
> > uint32_t pkg_offset;
> > uint32_t limit;
> > + uint32_t signature[3];
> >
> > /* Calculate & apply limits for different index ranges */
> > if (index >= 0xC0000000) {
> > limit = env->cpuid_xlevel2;
> > } else if (index >= 0x80000000) {
> > limit = env->cpuid_xlevel;
> > + } else if (index & 0x40000000) {
>
> Why did you decide to use (index & 0x40000000) instead of
> (index >= 0x40000000)? The latter would be more consistent with
> the rest of the code.
It was just a mistake.
> > + limit = 0x40000000;
>
> This is not strictly wrong, but it will make CPUID[0x40000001]
> return arbitrary bits (CPUID[env->cpuid_level]). Guests aren't
> supposed to look at CPUID[0x40000001] without checking
> CPUID[0x40000000] first, but probably it's safer to set
> limit = 0x40000001 and return all-zeroes on CPUID[0x40000001],
> just in case.
Ok
> > } else {
> > limit = env->cpuid_level;
> > }
> > @@ -2867,6 +2870,24 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> > }
> > break;
> > }
> > + case 0x40000000:
> > + /*
> > + * CPUID code in kvm_arch_init_vcpu() ignores stuff
> > + * set here, but we restrict to TCG none the less.
> > + */
> > + if (tcg_enabled() && cpu->expose_tcg) {
> > + memcpy(signature, "TCGTCGTCGTCG", 12);
> > + *eax = 0;
>
> On both KVM and Hyper-V, CPUID[0x40000000].EAX is the maximum
> CPUID function. KVM has the additional exception that eax=0 on
> the output is interpreted as 0x40000001.
>
> Setting this to 0x40000000 or 0x40000001 would make things more
> consistent for guests. Setting it to 0x40000001 would make it
> safer (see my other comment above).
Yep, makes sense.
>
>
> > + *ebx = signature[0];
> > + *ecx = signature[1];
> > + *edx = signature[2];
> > + } else {
> > + *eax = 0;
> > + *ebx = 0;
> > + *ecx = 0;
> > + *edx = 0;
> > + }
> > + break;
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 :|
prev parent reply other threads:[~2017-05-09 12:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 11:20 [Qemu-devel] [PATCH v3 0/2] Support CPUID signature for TCG Daniel P. Berrange
2017-05-09 11:20 ` [Qemu-devel] [PATCH v3 1/2] i386: rewrite way CPUID index is validated Daniel P. Berrange
2017-05-09 11:40 ` Eduardo Habkost
2017-05-09 11:20 ` [Qemu-devel] [PATCH v3 2/2] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf Daniel P. Berrange
2017-05-09 11:52 ` Eduardo Habkost
2017-05-09 12:39 ` Daniel P. Berrange [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=20170509123906.GG1669@redhat.com \
--to=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--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).