From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v7][PATCH 06/16] hvmloader/pci: skip reserved ranges Date: Wed, 15 Jul 2015 09:32:34 +0100 Message-ID: <55A636C202000078000911E9@mail.emea.novell.com> References: <1436420047-25356-1-git-send-email-tiejun.chen@intel.com> <1436420047-25356-7-git-send-email-tiejun.chen@intel.com> <55A3D5600200007800090330@mail.emea.novell.com> <55A4AE88.2000200@intel.com> <55A4F2270200007800090834@mail.emea.novell.com> <55A4EA54.60708@intel.com> <55A5138F0200007800090A71@mail.emea.novell.com> <55A5AF6F.1050305@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A5AF6F.1050305@intel.com> 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: Tiejun Chen Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 15.07.15 at 02:55, wrote: >> > I agree we'd better overhaul this since we already found something >>> unreasonable here. But one or two weeks is really not enough to fix this >>> with a bitmap framework, and although a bitmap can make mmio allocation >>> better, but more complicated if we just want to allocate PCI mmio. >>> >>> So could we do this next? I just feel if you'd like to pay more time >>> help me refine our current solution, its relatively realistic to this >>> case :) And then we can go into bitmap in details or work out a better >>> solution in sufficient time slot. >> >> Looking at how long it took to get here (wasn't this series originally >> even meant to go into 4.5?) and how much time I already spent > > Certainly appreciate your time. > > I didn't mean its wasting time at this point. I just want to express > that its hard to implement that solution in one or two weeks to walking > into 4.6 as an exception. > > Note I know this feature is still not accepted as an exception to 4.6 > right now so I'm making an assumption. After all this is a bug fix (and would have been allowed into 4.5 had it been ready in time), so doesn't necessarily need a freeze exception (but of course the bar raises the later it gets). Rather than rushing in something that's cumbersome to maintain, I'd much prefer this to be done properly. Jan