Re: [PATCH for-4.5 v6 05/16] tools: Add vmware_port support

[Don Slutz <dslutz@verizon.com>]

On 09/24/14 12:44, George Dunlap wrote:
> On 09/24/2014 05:31 PM, Don Slutz wrote:
>> On 09/23/14 08:20, Ian Campbell wrote:
>>> On Mon, 2014-09-22 at 12:42 -0400, Don Slutz wrote:
>>>>> The latter would allow moving to buildinfo.u.hvm, which would be 
>>>>> nicer
>>>>> from the libxl PoV, I think.
>>>> I could not find "buildinfo.u.hvm":
>>>>
>>>>
>>>> dcs-xen-54:~/xen>git grep buildinfo.u.hvm
>>>> dcs-xen-54:~/xen>
>>>>
>>>>
>>>> So unable to comment.
>>> It's in the idl, next to createinfo.
>>
>> I take that to mean:
>>
>>
>> libxl_domain_config = Struct("domain_config", [
>>     ("c_info", libxl_domain_create_info),
>>     ("b_info", libxl_domain_build_info),
>> ...
>>
>> I.E.
>>
>> b_info->u.hvm
>>
>>
>>>>> If yes then I still think you would want to set the default based on
>>>>> vmware-hw, wouldn't you?
>>>> I guess so since this is a BOOLEAN.
>>> defbool I hope.
>>
>> Yes.
>>
>>>>    Currently I do not know of a way to
>>>> say "set vmware_hw to 7
>>>> if vmware_port is true and vmware_hw is not specified".
>>> That's an error case, isn't it? Or at least a vmware_port is ignored
>>> case.
>>
>> Nope.  But I will agree that I have not done a lot with 3 (at least)
>> state booleans.  The 3 states being true, false, and not specified.
>>
>> And vmware_port is not ignored.
>>
>>> What I suggested was "if vmware_hw is non-zero then set vmware_port".
>>>
>>
>> I am reading that as "set vmware_port if not specified".  To avoid
>> complexity, I am treating vmware_hw as a boolean.  Using this
>> I get the following table:
>>
>> _hw   _port
>>  0     0        Just like today
>>  1     0        Only cpuid leaves change -- very unlikey
>>  1     1        Full VMware mode
>>  0     1        VMware hyper call mode.
>>
>> Adding U for unspecified:
>>
>> _hw   _port
>>  U     U        ==> _hw=0 _port=0
>>  0     U        ==> _hw=0 _port=0
>>  1     U        The case in question.
>>  U     0        ==> _hw=0 _port=0
>>  U     1        What I was talking about.
>>  0     0        Just like today
>>  1     0        Only cpuid leaves change -- very unlikey
>>  1     1        Full VMware mode
>>  0     1        VMware hyper call mode.
>>
>> The problem here is that vmware_hw is not a boolean and there is
>> currently not a value that lets you know it has not been specified.
>>
>> So I think it is just more confusing to have vmware_hw change
>> the default of vmware_port but the inverse is not true.
>
> So is it the case that if you specify vmware_hw with a value that your 
> guest isn't expecting, it may not work?
>

That is not the case for all versions of Linux I have tested with. And
since viridian should be set for windows (which hides the vmware_hw
setting), I do not expect this to be true.  Clearly someone could
write new code that fails because of this.


> I think the main thing Ian wants is probably a simple way for people 
> to just turn everything on.  Having vmware_hw!=0 => vmware_port 
> defaults to 1 seems like a reasonable way to do that.
>
> We could almost think of vmware_port as an "advanced" option that most 
> people don't need to set: i.e., you only need to set it if you want 
> one of the "unusual" modes (like CPUID-only or hypercall-only).
>

Ah, that makes sense.  Will do it.

    -Don Slutz


>  -George