Re: Preface working plan for altp2m during freeze exception

["Jan Beulich" <JBeulich@suse.com>]

>>> On 17.07.15 at 21:43, <ravi.sahita@intel.com> wrote:
> We are working on addressing review comments in this order (and you will see 
> this pattern in our review responses):
> 
> * Category 1 - Address review comments that affect ABI - these are of course 
> required and will be addressed first.
> 
> * Category 2 - Address review comments that do not affect ABI - we will try to 
> address ones that we think we can realistically meet within the time bounds - 
> we ask you for some flexibility on these. If these cannot be addressed within 
> the allotted exception time-frame, hopefully these wont be blockers for 4.6 
> since they can be addressed by follow-on patches.

Not sure - we've had bad experience with allowing code to go in with
the promise for later adjustments (which then never happened)...

> * Category 3 - Address review comments that are really design questions - 
> These we will try to address by short descriptions in review replies that 
> attempt to give a gist of the design we followed, but of course design 
> changes obviously cannot be done at this late stage - hopefully that is 
> expected.

If you really just mean questions on the design (rather than questions
possibly resulting int the requirement to change the design), then
that'd be fine of course. I think you understand that we shouldn't be
deferring issues that require design adjustments. Otoh I don't even
recall what design questions there were.

> * Category 4 - Address trivial changes as we naturally update patches, 
> however if we run out of time, some may remain un-addressed (to be taken care 
> of post 4.6).

See above (point 2).

> Can we please get a "yes - makes sense" sort of acknowledgement of this plan 
> from the Maintainers? 

Considering the limitations above, this is only a "maybe" from me.

> Y		N	[PATCH v3 05/15] x86/altp2m: basic data structures and support routines
> Status if not acked:	Category 3: we will write a short description of some 
> design questions in review replies
> 			Category 2: moving altp2m struct to be dynamically allocated - this has minor 
> benefit and big downside so will be lower priority, also some error handling 
> fixes

Big downside? You're not referring to the mechanical adjustments this
implies, are you?

> Y		N	[PATCH v3 07/15] VMX: add VMFUNC leaf 0 (EPTP switching) to emulator
> Status if not acked:	Category 2/3 - changes staged after Jan's feedback on v5 - 
> ack with those addressed in v6?

Let's see what v6 looks like.

> Y		N	[PATCH v3 08/15] x86/altp2m: add control of suppress_ve
> Status if not acked:	Now has r-b both Jan and George -  need maintainers ack on 
> this one please

Who do you refer to by "maintainer" here? I think the trivial
adjustment to xen/arch/x86/mm/mem_sharing.c can in the worst
case go in without Andres' ack. And everything else is covered
by George's authorship and review.

Jan