[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.5 v6 01/16] xen: Add support for VMware cpuid leaves

On 09/22/14 07:49, Andrew Cooper wrote:
On 20/09/14 19:07, Don Slutz wrote:
This is done by adding HVM_PARAM_VMWARE_HW. It is set to the VMware
virtual hardware version.

Currently 0, 3-4, 6-11 are good values.  However the
code only checks for == 0 or != 0.

Sigh, need to fix this statement, 7 is now checked for.

@@ -5692,6 +5701,29 @@ long do_hvm_op(unsigned long op, 
+            case HVM_PARAM_VMWARE_HW:
+                /*
+                 * This should only ever be set non-zero one time by
+                 * the tools and is read only by the guest.
+                 */
+                if ( d == current->domain )
curr_d instead of current->domain

Will do.

+                {
+                    rc = -EPERM;
+                    break;
+                }
+                if ( d->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN] )
+                {
+                    rc = -EXDEV;
+                    break;
+                }
+                if ( d->arch.hvm_domain.params[HVM_PARAM_VMWARE_HW] &&
This check is redundant.  Repeatedly setting 0 is still permitted
because of the break after this if().

No at all sure this is right. If it is set to 7, setting to 0 is not allowed. Which is what this if is checking for. This also allow multiple setting to 7 without error.
But setting to 7 and then 8 is not allowed.

+                     d->arch.hvm_domain.params[HVM_PARAM_VMWARE_HW] !=
+                     a.value )
+                {
+                    rc = -EEXIST;
+                    break;
+                }
+                break;

+ * VMware hardware version 7 defines some of these cpuid levels,
+ * below is a brief description about those.
+ *
+ *     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"
+ *
+ *     Leaf 0x40000010, Timing information.
+ * # EAX: (Virtual) TSC frequency in kHz.
+ * # EBX: (Virtual) Bus (local apic timer) frequency in kHz.
+ */
+int cpuid_vmware_leaves(uint32_t idx, uint32_t *eax, uint32_t *ebx,
+                        uint32_t *ecx, uint32_t *edx)
+    struct domain *d = current->domain;
+    if ( !is_vmware_domain(d) )
+        return 0;
+    switch ( idx - 0x40000000 )
+    {
+    case 0x0:
+        if ( d->arch.hvm_domain.params[HVM_PARAM_VMWARE_HW] >= 7 )
You are going to need some reference about VMWare versions.  The comment
for this function is fine for describing what "version 7" constitutes,
but how did you come about it?  What is supposed to be visible in the
leaves of a version less than 7 is selected by the toolstack, because I
doubt its all zeroes including the root leaf?

I was unable to find any clear statements on the VMware web site. This statement (from 2008)
can be found via google.  The best statement is from:


(Which is listed in the commit message). I have included part of that page here:


   Testing the CPUID hypervisor present bit

Intel and AMD CPUs have reserved bit 31 of ECX of CPUID leaf 0x1 as the hypervisor present bit. This bit allows hypervisors to indicate their presence to the guest operating system. Hypervisors set this bit and physical CPUs (all existing and future CPUs) set this bit to zero. Guest operating systems can test bit 31 to detect if they are running inside a virtual machine. Intel and AMD have also reserved CPUID leaves 0x40000000 - 0x400000FF for software use. Hypervisors can use these leaves to provide an interface to pass information from the hypervisor to the guest operating system running inside a virtual machine. The hypervisor bit indicates the presence of a hypervisor and that it is safe to test these additional software leaves. VMware defines the 0x40000000 leaf as the hypervisor CPUID information leaf. Code running on a VMware hypervisor can test the CPUID information leaf for the hypervisor signature. VMware stores the string "VMwareVMware" in EBX, ECX, EDX of CPUID leaf 0x40000000.

*Sample code*

int cpuid_check()
        unsigned int eax, ebx, ecx, edx;
        char hyper_vendor_id[13];

        cpuid(0x1, &eax, &ebx, &ecx, &edx);
        if  (bit 31 of ecx is set) {
                cpuid(0x40000000, &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';
                if (!strcmp(hyper_vendor_id, "VMwareVMware"))
                        return 1;               // Success - running under 
        return 0;

   Testing the virtual BIOS DMI information and the hypervisor port

Apart from the CPUID-based method for VMware virtual machine detection, VMware also provides a fallback mechanism for the following reasons:

 * This CPUID-based technique will not work for guest code running at
   CPL3 when VT/AMD-V is not available or not enabled.
 * The hypervisor present bit and hypervisor information leaf are only
   defined for products based on VMware hardware version 7.

     Virtual BIOS DMI information

The VMware virtual BIOS has many VMware-specific identifiers which programs can use to detect hypervisors. For the DMI string check, use the BIOS serial number and check for either string "VMware-" or "VMW" (for Mac OS X guests running on Fusion)


I tested it for 3, 4, 7, and 8 (the versions that I have easy access to) and 3 & 4 are all zero
(including root leaf) and 7 & 8 follow the above.

I just noticed that bit 31 of ECX of CPUID leaf 0x1 should also be zero (not yet tested) for
vmware_hw < 7.  Not at all sure what happens if I do this.

The best web pages I have found are:


Which is all about other features like "Max number of cores", etc.


Which is about what VMware products can use what versions.

(I can add these to the commit message; they do give some clues about vmware_hw
but none of which apply to the code in Xen.)

   -Don Slutz


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.