From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: [RFC] When to use "domain creation flag" or "HVM param"? Date: Mon, 23 Feb 2015 15:08:35 -0500 Message-ID: <54EB88C3.1000503@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel , Lars Kurth Cc: Keir Fraser , Ian Campbell , Andrew Cooper , Ian Jackson , Tim Deegan , Jan Beulich List-Id: xen-devel@lists.xenproject.org Currently Jan Beulich is not happy with the addition of a new domain creation flag. Andrew Cooper is not happy with a HVM param. I am stuck in the middle. This is from: On 02/23/15 11:28, Jan Beulich wrote: >> I was not sure on the way to go based on the emails. > > I think I said so before - we should come to some conclusion among > maintainers here first. I'm afraid besides Andrew and me no-one > really voiced any opinion; maybe worth for you to send out a > separate request-for-comments on this specific aspect... Below is some of the subsets of the email threads on this: Message-ID: <54DA5C69.1060409@terremark.com> References: <1412285417-19180-1-git-send-email-dslutz@verizon.com> <1412285417-19180-5-git-send-email-dslutz@verizon.com> <542DCA92.1030701@terremark.com> <542DD44F.6030101@terremark.com> <54B8F1740200007800055B42@mail.emea.novell.com> <54BFE768.3090309@terremark.com> <54C0C39F0200007800057F73@mail.emea.novell.com> <54C6643B.1@terremark.com> In-Reply-To: <54C6643B.1@terremark.com> Subject: Re: [PATCH v8 4/7] xen: Add vmware_port support Date: Tue, 10 Feb 2015 14:30:49 -0500 From: Don Slutz To: Don Slutz , Jan Beulich CC: Suravee Suthikulpanit , Andrew Cooper , Ian Campbell , George Dunlap , Ian Jackson , Stefano Stabellini , Eddie Dong , Jun Nakajima , Kevin Tian , xen-devel@lists.xen.org, Boris Ostrovsky , Konrad Rzeszutek Wilk , Keir Fraser , Tim Deegan On 01/26/15 10:58, Don Slutz wrote: > On 01/22/15 03:32, Jan Beulich wrote: >>>>> On 21.01.15 at 18:52, wrote: >>> On 01/16/15 05:09, Jan Beulich wrote: >>>>>>> On 03.10.14 at 00:40, wrote: >>>>> This is a new domain_create() flag, DOMCRF_vmware_port. It is >>>>> passed to domctl as XEN_DOMCTL_CDF_vmware_port. >>>> Can you explain why a HVM param isn't suitable here? >>>> >>> The issue is that you need this flag during construct_vmcb() and >>> construct_vmcs(). While Intel has vmx_update_exception_bitmap() >>> AMD does not. So when HVM param's are setup and/or changed there >>> currently is no way to adjust AMD's exception bitmap. >>> >>> So this is the simpler way. >> But the less desirable one from a design/consistency perspective. >> Unless other maintainers disagree, I'd like to see this changed. > > Ok, but will wait some time to see if "Unless other maintainers disagree" > While coding this is up I have hit issues that I need input on: As a HVM_PARAM_ item, I would assume I should be following what HVM_PARAM_VIRIDIAN does. It has this comment: case HVM_PARAM_VIRIDIAN: /* This should only ever be set once by the tools and read by the guest. */ Which is almost true. However the code allows you to change from 0 to non-zero any time in the life of the DomU. I am assuming that this is why xc_domain_save() and xc_domain_restore() save and restore this HVM_PARAM_ item. With the enable of vmware_port the same way, I feel it would be a bug to allow the enable after "create" to not also adjust QEMU. Currently there is no way for the hypervisor to tell QEMU to enable vmware_port handling. So to avoid adding this code to xen and QEMU, it looks to me that adding code to make this a true write only 1 time would be needed so that you cannot use the hyper call to change later. So, should I extend this change to cover other HVM_PARAM_? Is all this additional code (xc_domain_save(), xc_domain_restore(), write only 1 time) still better then a domain_create() flag? -Don Slutz Message-ID: <54E2FF9202000078000607A7@mail.emea.novell.com> References: <1412285417-19180-1-git-send-email-dslutz@verizon.com> <1412285417-19180-5-git-send-email-dslutz@verizon.com> <542DCA92.1030701@terremark.com> <542DD44F.6030101@terremark.com> <54B8F1740200007800055B42@mail.emea.novell.com> <54BFE768.3090309@terremark.com> <54C0C39F0200007800057F73@mail.emea.novell.com> <54C6643B.1@terremark.com> <54DA5C69.1060409@terremark.com> <54DB193F020000780005ED8F@mail.emea.novell.com> <54DB8B83.9000606@citrix.com> In-Reply-To: <54DB8B83.9000606@citrix.com>Subject: Re: [PATCH v8 4/7] xen: Add vmware_port support Date: Tue, 17 Feb 2015 07:45:06 +0000 From: Jan Beulich To: Andrew Cooper , Don Slutz CC: Suravee Suthikulpanit , Ian Campbell , George Dunlap , IanJackson , Stefano Stabellini , Eddie Dong , JunNakajima , Kevin Tian , xen-devel@lists.xen.org, Boris Ostrovsky , Konrad Rzeszutek Wilk , Keir Fraser , Tim Deegan >>> On 11.02.15 at 18:04, wrote: > On 11/02/15 07:56, Jan Beulich wrote: >>>>> On 10.02.15 at 20:30, wrote: >>> While coding this is up I have hit issues that I need input on: >>> >>> As a HVM_PARAM_ item, I would assume I should be following >>> what HVM_PARAM_VIRIDIAN does. It has this comment: >>> >>> case HVM_PARAM_VIRIDIAN: >>> /* This should only ever be set once by the tools and >>> read by the guest. */ >>> >>> Which is almost true. However the code allows you to change from 0 to >>> non-zero any time in the life of the DomU. I am assuming that this is >>> why xc_domain_save() and xc_domain_restore() save and restore this >>> HVM_PARAM_ item.>> I was not sure on the way to go based on the emails. > > I think I said so before - we should come to some conclusion among > maintainers here first. I'm afraid besides Andrew and me no-one > really voiced any opinion; maybe worth for you to send out a > separate request-for-comments on this specific aspect... >>> >>> With the enable of vmware_port the same way, I feel it would be a bug >>> to allow the enable after "create" to not also adjust QEMU. Currently >>> there is no way for the hypervisor to tell QEMU to enable vmware_port >>> handling. So to avoid adding this code to xen and QEMU, it looks to >>> me that adding code to make this a true write only 1 time would be >>> needed so that you cannot use the hyper call to change later. >>> >>> So, should I extend this change to cover other HVM_PARAM_? >>> >>> Is all this additional code (xc_domain_save(), xc_domain_restore(), >>> write only 1 time) still better then a domain_create() flag? >> I suppose for your case it's indeed the right approach. Which other >> params this may be true for as well I can't immediately say, but I'd >> certainly like to ask for adjustments to others to be in separate >> patches (and perhaps even a separate series), with proper >> rationale for each of them. I guess Andrew will have further input >> for you on this matter... > > My recommendation is still to use a creation flag. The described > problem is exactly the reason why I dislike the use of hvmparams for > booleans like this which really do need to be consistent for the > lifetime of the guest. While I can see your point, HVM params are much better scalable (and more obviously architecture specific) than creation flags... Jan Message-ID: <54EB4FE002000078000628F7@mail.emea.novell.com> References: <1424127915-27004-1-git-send-email-dslutz@verizon.com> <1424127915-27004-6-git-send-email-dslutz@verizon.com> In-Reply-To: <1424127915-27004-6-git-send-email-dslutz@verizon.com> Subject: Re: [PATCH v9 05/13] xen: Add vmware_port support Date: Mon, 23 Feb 2015 15:05:52 +0000 From: Jan Beulich To: Don Slutz CC: Aravind Gopalakrishnan , Suravee Suthikulpanit , Andrew Cooper , Ian Campbell , George Dunlap , Ian Jackson , Stefano Stabellini , Eddie Dong , Jun Nakajima , Kevin Tian , xen-devel@lists.xen.org, Boris Ostrovsky , Konrad Rzeszutek Wilk , Keir Fraser , Tim Deegan >>> On 17.02.15 at 00:05, wrote: > This includes adding is_vmware_port_enabled > > This is a new domain_create() flag, DOMCRF_vmware_port. It is > passed to domctl as XEN_DOMCTL_CDF_vmware_port. As indicated before, I don't think this is a good use case for a domain creation flag. Some of the others we have may not be either, but as I have said quite often recently - let's not make the situation worse by following bad examples. -Don Slutz