From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Preface working plan for altp2m during freeze exception Date: Mon, 20 Jul 2015 08:11:52 +0100 Message-ID: <55ACBB580200007800092E2D@mail.emea.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ravi Sahita Cc: Tim Deegan , Wei Liu , Ian Campbell , George Dunlap , Andrew Cooper , Ian Jackson , Edmund H White , "xen-devel@lists.xen.org" , Jun Nakajima , "tlengyel@novetta.com" , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org >>> On 17.07.15 at 21:43, 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