From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [V2 PATCH 0/8]: PVH dom0.... Date: Mon, 25 Nov 2013 10:49:14 +0000 Message-ID: <52932B2A.4040205@eu.citrix.com> References: <1385165018-25933-1-git-send-email-mukesh.rathor@oracle.com> <529321150200007800106660@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VktjW-0003oS-HH for xen-devel@lists.xenproject.org; Mon, 25 Nov 2013 10:49:38 +0000 In-Reply-To: <529321150200007800106660@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , keir.xen@gmail.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 11/25/2013 09:06 AM, Jan Beulich wrote: >>>> On 23.11.13 at 01:03, Mukesh Rathor wrote: >> These patches implement PVH dom0. Please note there is 1 fixme in >> this entire series that is being addressed under a different patch >> series. PVH dom0 creation is disabled until then. >> >> Patches 1 thru 4 implement changes in and around construct_dom0. >> Patches 5 thru 7 are to support tool stack on PVH dom0, and have >> been mostly looked at in the past. Finally, patch 8 adds option to >> boot a dom0 in PVH mode. >> >> These patches are based on c/s: b18e2d9 with the addition of fixes >> in epte_get_entry_emt and Roger's AP bringup/cleanup patches. > George, > > assuming we can get the remaining issues sorted out within > reasonable time, I'm inclined to recommend taking these despite > the code freeze. What's your opinion in this regard? I hadn't even looked at them, assuming that "PVH for dom0" had missed the feature freeze. Within our decision framework, we would accept this series if we considered PVH dom0 to be a "blocker" for the release -- a feature that is strategically important enough to risk slipping the release significantly. That's the basis on which the ARMv8 stuff got in. I assume (without having looked at all) that this series introduces new interfaces for PVH. So in addition to the normal risk that a series like this may break existing functionality, there is the additional risk that by rushing the feature in at the last minute, we may not have had enough time for the interface to be reviewed, and we may end up having to support an interface that wasn't well thought-out. So the important questions are: * Is there a good reason that this feature can't wait until 4.5? * What is the risk of these changes breaking existing functionality? * What is the risk that the new interfaces will turn out to be a bad fit or difficult to support going forward? -George