[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
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 nicerfrom 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.hvmIf 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |