Re: [PATCH v2 1/3] Add vmware_hw to xl.cfg

[Don Slutz <dslutz@verizon.com>]

On 09/09/14 05:39, Ian Campbell wrote:
> On Mon, 2014-09-08 at 15:16 -0400, Don Slutz wrote:
>> On 09/08/14 09:17, Ian Campbell wrote:
>>> On Mon, 2014-09-01 at 11:33 -0400, Don Slutz wrote:
>>>> If non-zero then
>>>>     Return VMware's cpuid leaves.
>>>>     Not doing the hardcoded IRQ9 on PIIX4 ACPI PM.
>>> Please can you say a words about why this is and what the implications
>>> are?
>> Duplicate -- windows activation.
>>
>>>>     Force use of VMware's VGA in QEMU.
>>>>
>>>> The support of hypervisor cpuid leaves has not been agreed to.
>>> Who needs to agree to this? Just us or do we need to be seeking
>>> consensus with other hypervisors?
>> Possible consensus with other hypervisors.    The 2 that are an issue
>> if MicroSoft (Hyper-V, viridian) and VMware.  Xen is not the issue.
>>
>>
>>>> So based on this, I picked the order:
>>>>
>>>> 0x40000000 is viridian, vmware or xen
>>>> 0x40000100 is vmware or xen
>>>> 0x40000200 is xen
>>> Which is another way of saying that the enabled options will be
>>> presented in the order viridian, vmware, xen.
>>>
>> Yes.
>>
>>>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>>>> index f1fc906..34fb021 100644
>>>> --- a/docs/man/xl.cfg.pod.5
>>>> +++ b/docs/man/xl.cfg.pod.5
>>>> @@ -1139,6 +1139,12 @@ some other Operating Systems and in some circumstance can prevent
>>>>    Xen's own paravirtualisation interfaces for HVM guests from being
>>>>    used.
>>>>    
>>>> +=item B<vmware_hw=NUMBER>
>>>> +
>>>> +Turns on or off the exposure of VMware cpuid.  The number is the
>>>> +VMware's hardware version number, where 0 is off.  If on it also
>>>> +forces the use of VMware's VGA in QEMU.
>>> Do you have a reference of the non-zero values of this field? How can a
>>> user determine what the correct number to use is?
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746
>>
>> For most uses, any non-zero is good enough.  Where it matters is how
>> QEMU presents emulated hardware.  VMware changes pci config space
>> based on this number which is stored in a .vmx file.
>>
>> Is vmware_hw too short?  Should I use vmware_virtual_hardware_version?
>>
>> or just adjust the xl.cfg.pod.5 description?
> Just updating the description to give users some clue as to what number
> they should use would be enough.

How does the following look:

   vmware_hw numbers come from VMware config files.

   In a .vmx it is virtualHW.version

   In a .ovf it is part of the value of vssd:VirtualSystemType

   for vssd:VirtualSystemType == vmx-07, vmware_hw = 7

Should I refer them to the vmware web site?

> I think you are implying that there are occasions where a user would
> care about which specific value is used, so turning this into a boolean
> isn't good enough. But an enum might be appropriate. (see below)

Yes, a boolean is not enough.

>>> Other than parroting this value back to the guest in a cpuid leaf does
>>> this value control anything else? If so then we may want to consider
>>> something like an enum to allow us to advertise more precisely which
>>> versions of vmware we are prepared to ape, but at the least we need to
>>> range check this input somewhere along the way.
>> See above, mostly just QEMU.
> What does qemu do with a number which it doesn't understand, perhaps
> corresponding to a newer vmware version which it hasn't learnt about
> yet?

My version currently checks for various ranges.  Like != 0, >= 4,
 >= 4 && < 7, >= 7.  I do not expect that I can upstream it with this,
but it should be similar.


> This sort of issue is why I was proposing an enum, or at least some sort
> of range checking.

Since most of the use is in QEMU, I see no need for an enum in xen.
All xen uses I know of are == 0 or != 0.  I can add some range checking
but think a warning might be better so that a newer QEMU with support
for a given value could be used with an older xen without change to
xen.

     -Don Slutz


> Ian.
>