Xen project Mailing List

On Wed, Sep 17, 2014 at 6:05 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 17.09.14 at 06:11, <eshelton@xxxxxxxxx> wrote:
> In October 2008 (see http://http://lwn.net/Articles/301888/),
> VMware proposed (and now implements) a generic hypervisor leaf
> 0x40000010 to provide timing information - specifically, the TSC
> frequency and the bus frequency in kHz. Some operating systems,
> including OS X, make use of these values to perform hypervisor-aware
> timing. OS X makes use of this information without regard to the
> hypervisor vendor ID signature returned in leaf 0x40000000.

So that proposal talks (bogusly) about an these leaves being an
interface between hypervisors and _Linux_ guests, yet you claim
it's needed/desired for OS X. Apart from this just being a proposal
(with no indication towards where a proper specification would be),
making CPUID behavior depend on guest type is pretty contrary to
the general idea of full virtualization (where the hypervisor should
make as little assumptions about the guest as possible).

I was not proposing anything other than guest-agnostic behavior, and my patch reflects that. For what it's worth, I don't think VMware's original proposal suggested guest-specific behavior; instead, it notes "a hypervisor can expose a different CPUID interface depending on the guest OS type that is specified by the VM configuration." Doesn't Xen do exactly that when an xl.cfg includes "viridian=1", since it enables leaves not otherwise provided?

Anyway, in _practice_ I believe VMware, at least by default, makes the 0x40000010 leaf available for all guests. In effect, I suppose I am proposing that Xen endorses making this timing information available to all guests, perhaps rendering this behavior more of a de facto standard behavior - at least across the two most popular hypervisors.

I note that Don Slutz has a patchset out (subject: "Xen VMware tools support"), which would also implement the 0x40000010 hypervisor leaf. A difference in my approach is that no "vmware=1" in xl.cfg or its equivalent, and any other baggage that may come along with that, is required to make this information available to guests.

Also, btw., providing a proper link would have helped too.

My apologies on the broken link - my email client's cut & paste behavior caught me by surprise.

As to the patch itself - is this

> + case 5 ... 15:
> + *eax = 0; /* Reserved */
> + *ebx = 0; /* Reserved */
> + *ecx = 0; /* Reserved */
> + *edx = 0; /* Reserved */
> + break;

really needed?

Jan

While looking into this issue, I noticed some CPUID scanning utilities will read 0x40000000 to determine the largest leaf, and then read each and every leaf up to the largest one (e.g., leaves 0x40000001-0x40000010). Is it a problem if reads to leaves 0x40000005-0x4000000e fall through to the BUG() in the default case? If not, then the 5 ... 15 portion of the switch is not needed.

Eric

Re: [Xen-devel] [PATCH] x86/traps: hypervisor leaf 0x40000010 timing info