From: "H. Peter Anvin" <hpa@zytor.com>
To: akataria@vmware.com
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
avi@redhat.com, Rusty Russell <rusty@rustcorp.com.au>,
Zachary Amsden <zach@vmware.com>, Dan Hecht <dhecht@vmware.com>,
Jun.Nakajima@Intel.Com
Subject: Re: Use CPUID to communicate with the hypervisor.
Date: Fri, 26 Sep 2008 17:09:00 -0700 [thread overview]
Message-ID: <48DD799C.3070706@zytor.com> (raw)
In-Reply-To: <1222472815.29886.43.camel@alok-dev1>
Alok Kataria wrote:
> From: Alok N Kataria <akataria@vmware.com>
>
> This patch proposes to use a cpuid interface to detect if we are running on an
> hypervisor.
> The discovery of a hypervisor is determined by bit 31 of CPUID#1_ECX, which is
> defined to be "hypervisor present bit". For a VM, the bit is 1, otherwise it is
> set to 0. This bit is not officially documented by either Intel/AMD yet, but
> they plan to do so some time soon, in the meanwhile they have promised to keep
> it reserved for virtualization.
>
> Also, Intel & AMD have reserved the cpuid levels 0x40000000 - 0x400000FF for
> software use. Hypervisors can use these levels to provide an interface to pass
> information from the hypervisor to the guest. This is similar to how we extract
> information about a physical cpu by using cpuid.
> XEN/KVM are already using the info leaf to get the hypervisor signature.
>
> VMware hardware version 7 defines some of these cpuid levels, below is a brief
> description about those. These levels can be implemented by other hypervisors
> too so that Linux has a standard way of communicating to any hypervisor.
>
> Leaf 0x40000000, Hypervisor CPUID information
> # EAX: The maximum input value for hypervisor CPUID info (0x40000010).
> # EBX, ECX, EDX: Hypervisor vendor ID signature. E.g. "VMwareVMware"
>
This is great, obviously... although we'll have to deal with legacy
methods for a while if not indefinitely (just as we have to for
pre-CPUID processors).
>
> +static void __init detect_hypervisor(void)
> +{
> + if (cpu_has_hypervisor) {
> + unsigned int eax, ebx, ecx, edx;
> + char hyper_vendor_id[13];
> +
> + cpuid(HYPERVISOR_INFO_LEAF, &eax, &ebx, &ecx, &edx);
> + memcpy(hyper_vendor_id + 0, &ebx, 4);
> + memcpy(hyper_vendor_id + 4, &ecx, 4);
> + memcpy(hyper_vendor_id + 8, &edx, 4);
> + hyper_vendor_id[12] = '\0';
> + printk(KERN_INFO "Hypervisor vendor id %s\n", hyper_vendor_id);
> + }
> +}
> +
This should be broken out into a separate file in cpu/*, because we
*will* need to detect hypervisors by other means.
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -345,16 +345,38 @@ failed:
> return 0;
> }
>
> +unsigned long hypervisor_tsc_freq(void)
> +{
> + unsigned long tsc_khz;
> + unsigned int max_cpuid_leaf;
> +
> + if (cpu_has_hypervisor) {
> + max_cpuid_leaf = cpuid_eax(HYPERVISOR_INFO_LEAF);
> + if (max_cpuid_leaf >= HYPERVISOR_TIMING_LEAF) {
> + tsc_khz = cpuid_eax(HYPERVISOR_TIMING_LEAF);
> + printk(KERN_INFO
> + "TSC frequency read from hypervisor\n");
> + return tsc_khz;
> + }
> + }
> + return 0;
> +}
> +
I would call this "vmware_tsc_freq()" because it is a VMWare-defined
interface... you can't just poke at 0x40000010 and assume it is using
the VMWare definition.
In order for *that* to be safe, you'd have to have well-defined ranges
for different virtualization vendors where each of them can define their
own stuff.
> diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h
> index ee7cbb3..70ca49b 100644
> --- a/include/asm-x86/processor.h
> +++ b/include/asm-x86/processor.h
> @@ -124,6 +124,27 @@ struct cpuinfo_x86 {
> #define X86_VENDOR_UNKNOWN 0xff
>
> /*
> + * Intel & AMD have reserved the cpuid levels 0x40000000 - 0x400000FF for
> + * software use. Hypervisors can use these levels to provide an interface
> + * to pass information from the hypervisor to the guest. This is similar
> + * to how we extract information about a physical cpu by using cpuid.
> + */
> +
> +/*
> + * This CPUID leaf returns the information about the hypervisor.
> + * EAX : maximum input value for CPUID supported by the hypervisor.
> + * EBX, ECX, EDX : Hypervisor vendor ID signature. E.g. VMwareVMware.
> + */
> +#define HYPERVISOR_INFO_LEAF 0x40000000
> +/*
> + * This leaf gets timing information from the hypervisor.
> + * EAX: (Virtual) TSC frequency in kHz.
> + * EBX: (Virtual) Bus (local apic timer) frequency in kHz.
> + * ECX, EDX: RESERVED
> + */
> +#define HYPERVISOR_TIMING_LEAF 0x40000010
> +
<asm/processor.h> is the wrong place for this, and these constants
should have CPUID_ in them to tell what they fundamentally are.
My preference would be for <asm/cpuid.h>, but otherwise
<asm/cpufeature.h> wouldn't be entirely wrong.
-hpa
next prev parent reply other threads:[~2008-09-27 0:14 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 23:46 Use CPUID to communicate with the hypervisor Alok Kataria
2008-09-27 0:09 ` H. Peter Anvin [this message]
2008-09-27 0:30 ` Alok Kataria
2008-09-27 0:32 ` H. Peter Anvin
2008-09-27 0:59 ` Nakajima, Jun
2008-09-27 1:55 ` H. Peter Anvin
2008-09-27 4:52 ` Nakajima, Jun
2008-09-29 20:56 ` Karel Zak
2008-09-27 1:02 ` Jeremy Fitzhardinge
2008-09-27 1:28 ` H. Peter Anvin
2008-09-27 3:11 ` Alok Kataria
2008-09-27 4:20 ` H. Peter Anvin
2008-09-27 5:37 ` Alok Kataria
2008-09-28 5:01 ` Jeremy Fitzhardinge
2008-09-29 9:28 ` Tim Deegan
2008-09-29 9:44 ` Avi Kivity
2008-09-29 6:55 ` Gleb Natapov
2008-09-29 7:37 ` Avi Kivity
2008-09-29 9:08 ` Bernd Eckenfels
2008-09-29 9:33 ` Gleb Natapov
2008-09-29 15:32 ` Nakajima, Jun
2008-09-30 9:16 ` Avi Kivity
2008-09-29 8:24 ` Gerd Hoffmann
2008-09-29 17:55 ` Alok Kataria
2008-09-29 17:58 ` H. Peter Anvin
2008-09-29 18:46 ` Gerd Hoffmann
2008-09-29 19:38 ` Alok Kataria
2008-09-29 20:31 ` H. Peter Anvin
2008-09-29 20:55 ` Nakajima, Jun
2008-09-29 21:07 ` H. Peter Anvin
2008-09-29 21:28 ` Jeremy Fitzhardinge
2008-09-29 21:49 ` H. Peter Anvin
2008-09-29 23:20 ` Zachary Amsden
2008-09-30 0:33 ` H. Peter Anvin
2008-09-30 0:12 ` Alok Kataria
2008-09-30 0:31 ` H. Peter Anvin
2008-09-30 0:56 ` Nakajima, Jun
2008-09-30 0:58 ` H. Peter Anvin
2008-09-30 1:14 ` Nakajima, Jun
2008-09-30 2:21 ` H. Peter Anvin
2008-09-30 3:14 ` Nakajima, Jun
2008-09-30 3:48 ` H. Peter Anvin
2008-09-29 22:46 ` Gerd Hoffmann
2008-09-30 0:33 ` Alok Kataria
2008-09-30 8:11 ` Gerd Hoffmann
2008-09-30 16:42 ` Zachary Amsden
2008-10-02 11:52 ` Avi Kivity
2008-10-01 4:35 ` [Hypervisors] TSC frequency change Alok Kataria
2008-10-01 9:47 ` Gerd Hoffmann
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=48DD799C.3070706@zytor.com \
--to=hpa@zytor.com \
--cc=Jun.Nakajima@Intel.Com \
--cc=akataria@vmware.com \
--cc=avi@redhat.com \
--cc=dhecht@vmware.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=zach@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox