From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][PATCH 06/16] hvmloader/pci: skip reserved ranges Date: Wed, 15 Jul 2015 19:20:08 +0800 Message-ID: <55A641E8.4000602@intel.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> <55A5E122.7030203@intel.com> <55A6374E02000078000911EC@mail.emea.novell.com> <55A6210E.8080406@intel.com> <55A64386020000780009132E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: 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 2015/7/15 19:05, George Dunlap wrote: > On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote: >>>>> On 15.07.15 at 10:59, wrote: >>> On 2015/7/15 16:34, Jan Beulich wrote: >>>>>>> On 15.07.15 at 06:27, wrote: >>>>> Furthermore, could we have this solution as follows? >>>> >>>> Yet more special casing code you want to add. I said no to this >>>> model, and unless you can address the issue _without_ adding >>>> a lot of special casing code, the answer will remain no (subject >>> >>> What about this? >>> >>> @@ -301,6 +301,19 @@ void pci_setup(void) >>> pci_mem_start <<= 1; >>> } >>> >>> + for ( i = 0; i < memory_map.nr_map ; i++ ) >>> + { >>> + uint64_t reserved_start, reserved_size; >>> + reserved_start = memory_map.map[i].addr; >>> + reserved_size = memory_map.map[i].size; >>> + if ( check_overlap(pci_mem_start, pci_mem_end - pci_mem_start, >>> + reserved_start, reserved_size) ) >>> + { >>> + printf("Reserved device memory conflicts current PCI memory.\n"); >>> + BUG(); >>> + } >>> + } >> >> So what would the cure be if someone ran into this BUG() (other >> than removing the device associated with the conflicting RMRR)? >> Afaics such a guest would remain permanently unbootable, which >> of course is not an option. > > Is not booting worse than what we have now -- which is, booting > successfully but (probably) having issues due to MMIO ranges > overlapping RMRRs? Its really so rare possibility here since in the real world we didn't see any RMRR regions >= 0xF0000000 (the default pci memory start.) And I already sent out a little better revision in that ensuing email so also please take a review if possible :) > > This patch series as a whole represents a lot of work and a lot of > tangible improvements to the situation; and (unless the situation has > changed) it's almost entirely acked apart from the MMIO placement > part. If there is a simple way that we can change hvmloader so that > most (or even many) VM/device combinations work properly for the 4.6 > release, then I think it's worth considering. > Current MMIO allocation mechanism is not good. So we really need to reshape that, but we'd better do this with some further discussion in next release :) Thanks Tiejun