From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V3 PATCH 0/9]: PVH dom0.... Date: Sun, 1 Dec 2013 15:53:45 -0800 Message-ID: <20131201155345.57f832d7@mantra.us.oracle.com> References: <1385519230-21132-1-git-send-email-mukesh.rathor@oracle.com> <529731E6.5050201@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <529731E6.5050201@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 Cc: Xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com, JBeulich@suse.com List-Id: xen-devel@lists.xenproject.org On Thu, 28 Nov 2013 12:07:02 +0000 George Dunlap wrote: > On 11/27/2013 02:27 AM, Mukesh Rathor wrote: ....... > So a couple of thoughts from a release perspective. > > Releasing *code* as "experimental" means, "it may work or it may not; > use at your own risk". If people use it and it works, then great; > they can expect that the code will only get better. > > However, releasing an *interface* as "experimental" means, "it may > work for you now, but it may not work later when we change the > interface". While this is nice in theory, in practice, once something > works, people may begin to rely on it and we may end up having to > support it anyway. So the Linux interface cannot really be labelled > "experimental"; we have to be reasonably certain that we can support > it going forward. > > Benefits: > > We have a fairly solid precedent for releasing features as > "experimental" or "tech preview". This allows a much wider testing > and feedback. If it turns out to be robust enough, people may even > be able to use it, gaining the potential performance advantages. > > Someone could make an argument the other way: that the best thing to > do would be to check it in at the beginning of the release cycle, get > it well tested, and then release it as "ready" for 4.5, without going > through an "experimental" phase. Both arguments have their merits; > but since current way we do things hasn't caused any problems and > seems to be working OK, it seems best to follow precedent, and assume > that a tech preview will be beneficial. > > Risks, bugs: > > All of the actual functional changes in this series are predicated on > "if(is_pvh_domain())", so in theory they should only have an effect > on PVH guests. (There is, of course, a small risk that there will be > a mistake here.) It introduces a new p2m type, but since it is the > only one that uses it, bugs should only affect PVH, and not other > functionality. > > Risks, interface: > > This patch series only adds two things to the interface with Linux: > XENMAPSPACE_gmfn_foreign and XENMEM_add_to_physmap_range. > These are already used and available in the ARM side. > > Normally I'd be afraid of accepting new interfaces at this stage in > the game, as I'd be afraid that we hadn't had enough time to make > sure it's something we want to support going forward. However, since > this is just duplicating an interface already in use on the ARM side, > I think the interface *has* been thought of for some time. This > makes is much more likely to be worth the risk; if the ARM side has > used it for 6 months without finding a problem with it, it seems > unlikely that the x86 side will be particularly different. > > So on the whole, there is a benefit (if a bit nebulous) to having it > in, and a reasonably low risk; and it's not clear that the risk will > be significantly mitigated by waiting another 6 months. I'm > therefore inclined to give it a release ack. > > Any thoughts? > Normally, I'd be uncomfortable myself, but given that the feature is marked experimental, and the fact that the changes are hidden behind is_pvh_domain(), thereby leaving normal PV/HVM paths as before, gives me the comfort. But ultimately your call, and I"d be OK either way. thanks mukesh