From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH for-4.5 v6 05/16] tools: Add vmware_port support Date: Thu, 25 Sep 2014 15:17:12 +0100 Message-ID: <542423E8.5040108@eu.citrix.com> References: <1411236447-7435-1-git-send-email-dslutz@verizon.com> <1411236447-7435-6-git-send-email-dslutz@verizon.com> <1411393315.18331.104.camel@kazak.uk.xensource.com> <5420517B.9060602@terremark.com> <1411474847.1781.9.camel@kazak.uk.xensource.com> <5422F1DF.7040100@terremark.com> <1411644244.16473.35.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1411644244.16473.35.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: Kevin Tian , Keir Fraser , Eddie Dong , Stefano Stabellini , Ian Jackson , Tim Deegan , xen-devel@lists.xen.org, Jan Beulich , Aravind Gopalakrishnan , Jun Nakajima , Andrew Cooper , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.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