Re: [Xen-devel] [PATCH v3 11/13] x86/altp2m: define and implement alternate p2m HVMOP types.

[Ed White <edmund.h.white@xxxxxxxxx>]

On 07/06/2015 10:08 AM, Ian Jackson wrote:
> Ed White writes ("Re: [Xen-devel] [PATCH v3 11/13] x86/altp2m: define and 
> implement alternate p2m HVMOP types."):
>> On 07/06/2015 03:09 AM, Andrew Cooper wrote:
>>> I am still very much unconvinced by the argument against having a single
>>> HVMOP_altp2m and a set of subops.  do_domctl() and do_sysctl() are
>>> examples of a subop style hypercall with different XSM settings for
>>> different subops.
> ...
>> How do we get to a binding decision on whether making this change is
>> a prerequisite for acceptance or not? Changing the HVMOP encoding
>> means fairly extensive changes to the code in hvm.c, and the XSM
>> patch, and the code Tamas has written. It also necessitates significant
>> changes to all the code we use to test the intra-domain protection
>> model.
> 
> I have tried to find the discussons about this and I'm not sure I have
> found them all.  I found this:
> 
>   Subject: Re: [PATCH v2 09/12] x86/altp2m: add remaining support routines.
>   Date: Wed, 24 Jun 2015 11:06:45 -0700
>   Message-ID: <558AF1B5.4000801@xxxxxxxxx>
> 
>   On 06/24/2015 09:15 AM, Lengyel, Tamas wrote:
>   > This function IMHO should be merged with p2m_set_mem_access and should be
>   > triggerable with the same memop (XENMEM_access_op) hypercall instead of
>   > introducing a new hvmop one.
> 
>   I think we should vote on this. My view is that it makes XENMEM_access_op
>   too complicated to use. It also makes using this one specific altp2m
>   capability different to using any of the others -- especially if we adopt
>   Andrew's suggestion and make all the altp2m ops subops.
> 
> and the ensuing subthread, and this thread.  If there are others,
> could you please refer me to them ?
>

I believe, unless Tamas says otherwise, that we agreed the
HVMOP's in question and their implementations are sufficiently
different that we should not merge them.

The decision I'm looking for is on the suggestion Andrew made in
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03820.html.

That suggestion had not been made prior to that point, even though the
HVMOP's have not changed since the original patch series submitted in
January, but it now appears that it may be a requirement, not a
suggestion.

Our focus has very clearly been on inclusion in Xen 4.6, and changing
the HVMOP's in this way, with the attendant other changes required, puts
us at a substantial risk of not being feature-complete by Friday, which
is why I want to clarify it.

To be clear: this is not like the p2m set/get issue, where we have a
disagreement on design principles; it's just a large amount of work
being suggested late in the development cycle, and no-one has said
definitively whether or not we *have* to do it.

Ed
 
> If this is the same disagreement, it appears that at least Tamas
> (original author), Andrew Cooper (x86 maintainer) disagree with you.
> 
>> Feature freeze is Friday, and that's a lot to change, test, and get
>> approved.
>>
>> Who owns the decision?
> 
> Normally decisions are taken by the maintainers for the relevant area
> of code.  See the role of maintainer, as documented here:
> 
>   http://www.xenproject.org/governance.html
> 
>   Maintainers
> 
>   Maintainers own one or several components in the Xen tree. A
>   maintainer reviews and approves changes that affect their
>   components. It is a maintainer's prime responsibility to review,
>   comment on, co-ordinate and accept patches from other community
>   member's and to maintain the design cohesion of their
>   components. Maintainers are listed in a MAINTAINERS file in the root
>   of the source tree.
> 
> For the x86 API that would be:
> 
>   Keir Fraser <keir@xxxxxxx>
>   Jan Beulich <jbeulich@xxxxxxxx>
>   Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 
> 
> In practice, normally a decision by one maintainer would stand unless
> another maintainer disagrees.
> 
> In the usual course of events, a submitter who disagrees with a
> decision of a maintainer can ask another maintainer for a second
> opinion.  Usually this results in consensus.
> 
> I can see that Jan Beulich (who is the other active x86 maintainer -
> Keir is no longer very active) has been CC'd on a lot of this traffic.
> I don't see you having asked Jan for an opinion, although you did ask
> for a vote.  It would be helpful of Jan were to explicitly state his
> opinion.
> 
> Jan: what do you think ?
> 
> In principle, if the dispute is not resolved, committers could vote.
> We have (as a project) not yet needed to do this about a matter of
> code.  I don't think a vote to overrule the maintainers is likely
> here, although the views of other contributors - especially of
> committers and other maintainers will be influential with Jan and
> Andrew.
> 
> I hope this is helpful.
> 
> Thank,
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel