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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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 ?

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