| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
 Re: [Xen-devel] [PATCH for-4.5 v6 05/16] tools: Add vmware_port	support
 
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Don Slutz <dslutz@xxxxxxxxxxx>From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>Date: Thu, 25 Sep 2014 15:17:12 +0100Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>,	Eddie Dong <eddie.dong@xxxxxxxxx>,	Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>,	Ian Jackson <ian.jackson@xxxxxxxxxxxxx>,	Tim Deegan <tim@xxxxxxx>, xen-devel@xxxxxxxxxxxxx,	Jan Beulich <jbeulich@xxxxxxxx>,	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx>,	Jun Nakajima <jun.nakajima@xxxxxxxxx>,	Andrew Cooper <andrew.cooper3@xxxxxxxxxx>,	Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>,	Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>Delivery-date: Thu, 25 Sep 2014 14:18:06 +0000List-id: Xen developer discussion <xen-devel.lists.xen.org> 
 
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").  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]
In my other e-mail, I suggest that we make vmware_hw the "primary" 
configuration thing, and not even suggest using vmware_port unless they 
want one of the "unusual" configurations. 
 -George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
 
 |