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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-09-25 at 15:17 +0100, George Dunlap wrote:
> On 09/25/2014 12:24 PM, Ian Campbell wrote:
> > On Wed, 2014-09-24 at 12:31 -0400, 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
> > 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.
> > The third state is "default" as in: libxl sets something sensible based
> > on other criteria (internal choice, other settings etc).
> >
> >> 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.
> > The unspecified value is 0, surely? All of the rows with U under _hw can
> > be ignored, I am talking only about _port being a defbool.
> 
> You asked Don to add "vmware_hw != 0 => vmware_port ?= 1"  (Where ?= is 
> like make, "set if not already set").  Don then naturally thought


>  maybe 
> you might want to do the opposite: ("vmware_port != 0 => vmware_hw ?= 
> 7").

We don't want this (I've been trying say, badly obviously).

>   That's what Don is talking about with vmware_hw not being a 
> boolean: he can't tell the difference between:
> 
> vmware_port=1
> vmware_hw=0
> 
> and:
> 
> vmware_port=1
> [nothing about vmware_hw]

Then vmware_hw == 0 (which I think you know, but to be clear)

> In my other e-mail, I suggest that we make vmware_hw the "primary" 
> configuration thing,

This is what I've been trying to get at...

>  and not even suggest using vmware_port unless they 
> want one of the "unusual" configurations.

Indeed. Which the second of your examples is doing, just like the first.

Ian.


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