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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >   
> >                   break;
> >               }
> > +            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.
> > + * # ECX, EDX: RESERVED
> > + */
> > +
> > +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:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458 

(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 
VMware
        }
        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:

http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc%2FGUID-789C3913-1053-4850-A0F0-E29C3D32B6DA.html

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

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007240

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


> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel