public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alok Kataria <akataria@vmware.com>
To: "H. Peter Anvin" <hpa@zytor.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" <avi@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Zach Amsden <zach@vmware.com>, Daniel Hecht <dhecht@vmware.com>,
	"Jun.Nakajima@Intel.Com" <Jun.Nakajima@Intel.Com>
Subject: Re: Use CPUID to communicate with the hypervisor.
Date: Fri, 26 Sep 2008 17:30:03 -0700	[thread overview]
Message-ID: <1222475403.29886.57.camel@alok-dev1> (raw)
In-Reply-To: <48DD799C.3070706@zytor.com>

Hi Peter,

Thanks for the comments, please find my replies below.

On Fri, 2008-09-26 at 17:09 -0700, H. Peter Anvin wrote:
> Alok Kataria wrote:

> >
> > 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).

Ok, do you think we should keep those (legacy) interfaces separate so
that they can be phased out whenever the time is right. 

> 
> >
> > +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.
Ok, i will  do that.

> > --- 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.

I would like to see this as a generic hypervisor way to get frequency
rather than a VMware specific thingy. 
> 
> 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.

My motivation for doing this is to have a standard across all the
hypervisor's. If all the different hypervisor guys can come to some
sought of consensus on the various hypervisor leafs that would help keep
this simple and a lot more maintainable.

> 
> > 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.

Ok makes sense, will do that.

Thanks,
Alok
> 
>         -hpa


  reply	other threads:[~2008-09-27  0:30 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
2008-09-27  0:30   ` Alok Kataria [this message]
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=1222475403.29886.57.camel@alok-dev1 \
    --to=akataria@vmware.com \
    --cc=Jun.Nakajima@Intel.Com \
    --cc=avi@redhat.com \
    --cc=dhecht@vmware.com \
    --cc=hpa@zytor.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