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 14:29:48 -0400 Message-ID: <54230D9C.4050109@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> <5422F1DF.7040100@terremark.com> <5422F4E8.8050405@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5422F4E8.8050405@eu.citrix.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: George Dunlap , 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/14 12:44, George Dunlap wrote: > 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? > That is not the case for all versions of Linux I have tested with. And since viridian should be set for windows (which hides the vmware_hw setting), I do not expect this to be true. Clearly someone could write new code that fails because of this. > 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). > Ah, that makes sense. Will do it. -Don Slutz > -George