public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Zachary Amsden <zach@vmware.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Alok Kataria <akataria@vmware.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	"avi@redhat.com" <avi@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Daniel Hecht <dhecht@vmware.com>
Subject: Re: Use CPUID to communicate with the hypervisor.
Date: Mon, 29 Sep 2008 17:33:22 -0700	[thread overview]
Message-ID: <48E173D2.1030708@zytor.com> (raw)
In-Reply-To: <1222730405.27056.237.camel@bodhitayantram.eng.vmware.com>

Zachary Amsden wrote:
> 
> Aren't we overthinking / overdesigning this a bit?  It's not rocke
> science.  We'd like to have a leaf set aside for TSC frequency, and
> maybe another leaf in the future.  We think other vendors might find a
> static clock frequency leaf to be useful, so if that happens to be the
> case, feel free to re-use the leaf.
> 

No, I don't think we are.  Under the circumstances I do not think 
anything other than positive identification is unacceptable.

If anything, the whole concept of reusing interfaces is what

> We don't expect to see lots of proliferation of CPU leaves at all, in
> fact, we'd be flummoxed to propose more than one right now.  So
> basically a nicely written comment section explaining how the SW CPUID
> registers are layed out is probably sufficient.  Other vendors can add
> to it as they see fit, and Linux itself can be the central standard
> body.  After all, it's what we all work on, and it makes sense for
> everyone here, even MS, to have the software leaves defined in a public
> work.

NIH is a huge factor, and MS is worse than most.

> The whole thing is software defined so it's not a big deal if one or all
> parties eventually don't play well with others, grow up to become
> bullies with ADD, or simply autistic children who ignore the whole
> thing.  You can always make detection vendor dependent when that
> happens.
> 
> Right now there's nothing shockingly vendor dependent, just a whole lot
> of complicated proposals about how to define what the bits are going to
> define and not enough bits of information to actually express.  It seems
> perfectly okay for now to have new leaf proposals defined by fiat for
> now.
> 
> As long as there is a vendor-ID leaf, nobody is blocking any forward
> progress by adding a new non-conflicting leaf.  We can always add the
> meta-leafs required for decoding if something tangible materializes, but
> for now the TSC leaf seems pretty useful and I would probably want to
> proclaim it by fatwa, if I had such a power.

If someone had the power to proclaim it by fatwa we wouldn't have much 
to worry about.  Intel might have the power, but we as a group in this 
thread definitely do not.

However, it is clear the virtualization industry doesn't have their act 
together to the point where one can rely on anything but positive 
identification, unlike in the hardware space, where we can rely on 
implicit identification, because people aren't stepping on each other's 
toes.

	-hpa

  reply	other threads:[~2008-09-30  0:38 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
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 [this message]
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=48E173D2.1030708@zytor.com \
    --to=hpa@zytor.com \
    --cc=akataria@vmware.com \
    --cc=avi@redhat.com \
    --cc=dhecht@vmware.com \
    --cc=jeremy@goop.org \
    --cc=jun.nakajima@intel.com \
    --cc=kraxel@redhat.com \
    --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