From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Performance numbers on PV-on-HVM Date: Mon, 04 Oct 2010 12:23:14 -0700 Message-ID: <4CAA29A2.7000802@goop.org> References: <4CA2698B.5010901@xmerlin.org> <4CA4DD48.4030704@xmerlin.org> <20101001141308.GO2804@reaktio.net> <4CA65E78.1000400@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Christian Zoffoli List-Id: xen-devel@lists.xenproject.org On 10/04/2010 10:08 AM, Stefano Stabellini wrote: > On Mon, 4 Oct 2010, Stefano Stabellini wrote: >> On Fri, 1 Oct 2010, Jeremy Fitzhardinge wrote: >>>>> Hopefully Jeremy merges 2.6.32-pvhvm to xen/stable-2.6.32.x branch.. >>>> >>>> The problem is that Jeremy's stable branch is sufficiently different >>>> from stable 2.6.32 that the port in non-trivial. >>>> It would probably easier for him to cherry-pick the last 6 patches in >>>> the series. >>> I tried this, but it is a bit awkward: >>> >>> Two of them have already been applied verbatim. >>> >>> The blkfront name patch clashes with something similar that's already in >>> xen/next (the version I currently have does xlbd_reserve_minors(), but >>> this branch's patch doesn't). I don't know which version to take. >>> >> just take the latest version >> >>> The hvc console patches clash fairly badly with the dom0 ones; nothing >>> fundamental, but fiddly. >> skip them for now: they are not critical and at some point I'll rebase >> them on top of the "xen initial domain" series that has dom0 hvc_xen >> support and you'll be able to pull them without conflicts. >> >>> The balloon.c changes clash with the largepage ballooning stuff. >>> >> >> I have reworked the balloon patch on top of stable 2.6.32, I am attaching >> the patch to this email. > > of course if you would like me to prepare a branch on top of > stable-2.6.32.x I can do that as well A resolved merge would be better than rebasing onto stable-2.6.32.x. J