From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [V2 PATCH 0/8]: PVH dom0.... Date: Mon, 25 Nov 2013 11:57:15 +0100 Message-ID: <52932D0B.2060906@citrix.com> References: <1385165018-25933-1-git-send-email-mukesh.rathor@oracle.com> <529321150200007800106660@nat28.tlf.novell.com> <52932B2A.4040205@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vktqr-0004VS-GQ for xen-devel@lists.xenproject.org; Mon, 25 Nov 2013 10:57:13 +0000 In-Reply-To: <52932B2A.4040205@eu.citrix.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: George Dunlap , Jan Beulich Cc: xen-devel , keir.xen@gmail.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 25/11/13 11:49, George Dunlap wrote: > 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? I agree with everything above... > * What is the risk that the new interfaces will turn out to be a bad fit > or difficult to support going forward? But I don't think this applies to PVH Dom0, the DomU interface has already been marked as experimental, and subject to change. The same applies here, Dom0 PVH interface would be considered experimental.