All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: xen-devel <xen-devel@lists.xen.org>, Lars Kurth <lars.kurth@citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [RFC] When to use "domain creation flag" or "HVM param"?
Date: Mon, 23 Feb 2015 15:08:35 -0500	[thread overview]
Message-ID: <54EB88C3.1000503@terremark.com> (raw)

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 <dslutz@verizon.com>
To: Don Slutz <dslutz@verizon.com>, Jan Beulich <JBeulich@suse.com>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Andrew Cooper
<andrew.cooper3@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson
<ian.jackson@eu.citrix.com>, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>, Eddie Dong <eddie.dong@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>, Kevin Tian
<kevin.tian@intel.com>, xen-devel@lists.xen.org, Boris Ostrovsky
<boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>, Tim Deegan
<tim@xen.org>

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, <dslutz@verizon.com> wrote:
>>> On 01/16/15 05:09, Jan Beulich wrote:
>>>>>>> On 03.10.14 at 00:40, <dslutz@verizon.com> 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 <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Don Slutz
<dslutz@verizon.com>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Ian Campbell
<ian.campbell@citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
IanJackson <ian.jackson@eu.citrix.com>, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>, Eddie Dong <eddie.dong@intel.com>,
JunNakajima <jun.nakajima@intel.com>, Kevin Tian <kevin.tian@intel.com>,
xen-devel@lists.xen.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser
<keir@xen.org>, Tim Deegan <tim@xen.org>

>>> On 11.02.15 at 18:04, <andrew.cooper3@citrix.com> wrote:
> On 11/02/15 07:56, Jan Beulich wrote:
>>>>> On 10.02.15 at 20:30, <dslutz@verizon.com> 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 <JBeulich@suse.com>
To: Don Slutz <dslutz@verizon.com>
CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>, Suravee
Suthikulpanit <suravee.suthikulpanit@amd.com>, Andrew Cooper
<andrew.cooper3@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson
<ian.jackson@eu.citrix.com>, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>, Eddie Dong <eddie.dong@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>, Kevin Tian
<kevin.tian@intel.com>, xen-devel@lists.xen.org, Boris Ostrovsky
<boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>, Tim Deegan
<tim@xen.org>

>>> On 17.02.15 at 00:05, <dslutz@verizon.com> 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

             reply	other threads:[~2015-02-23 20:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23 20:08 Don Slutz [this message]
2015-02-24 10:24 ` [RFC] When to use "domain creation flag" or "HVM param"? Tim Deegan
2015-02-24 10:31   ` Jan Beulich
2015-02-24 10:43     ` Tim Deegan
2015-02-24 10:50     ` Andrew Cooper
2015-02-24 16:48       ` Don Slutz
2015-02-26 10:52       ` Tim Deegan
2015-02-26 11:09         ` Lars Kurth
2015-02-26 15:33           ` Julien Grall
2015-02-26 15:43             ` Tim Deegan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EB88C3.1000503@terremark.com \
    --to=dslutz@verizon.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=lars.kurth@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.