[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
- To: George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Don Slutz <dslutz@xxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
- From: Don Slutz <dslutz@xxxxxxxxxxx>
- Date: Wed, 24 Sep 2014 14:29:48 -0400
- Cc: Tim Deegan <tim@xxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Eddie Dong <eddie.dong@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
- Delivery-date: Wed, 24 Sep 2014 18:30:02 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|