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: Wed, 24 Sep 2014 17:44:24 +0100 Message-ID: <5422F4E8.8050405@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5422F1DF.7040100@terremark.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: Don Slutz , Ian Campbell Cc: Tim Deegan , Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , 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/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? 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). -George