From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH for-4.5 v6 05/16] tools: Add vmware_port support Date: Wed, 24 Sep 2014 12:31:27 -0400 Message-ID: <5422F1DF.7040100@terremark.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1411474847.1781.9.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 Cc: Tim Deegan , Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , George Dunlap , Ian Jackson , Eddie Dong , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Jan Beulich , Andrew Cooper , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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. -Don Slutz >> Which would be >> the inverse. I lean to >> not having the default of vmware_port based on vmware_hw.