[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges
>>> On 18.06.15 at 08:17, <tiejun.chen@xxxxxxxxx> wrote: > On 2015/6/17 17:24, Jan Beulich wrote: >>>>> On 17.06.15 at 11:18, <tiejun.chen@xxxxxxxxx> wrote: >>> On 2015/6/17 17:02, Jan Beulich wrote: >>>>>>> On 17.06.15 at 10:26, <tiejun.chen@xxxxxxxxx> wrote: >>>>> Something hits me to generate another idea, >>>>> >>>>> #1. Still allocate all devices as before. >>>>> #2. Lookup all actual bars to check if they're conflicting RMRR >>>>> >>>>> We can skip these bars to keep zero. Then later it would make lookup >>>>> easily. >>>>> >>>>> #3. Need to reallocate these conflicting bars. >>>>> #3.1 Trying to reallocate them with the remaining resources >>>>> #3.2 If the remaining resources aren't enough, we need to allocate them >>>>> from high_mem_resource. >>>> >>>> That's possible onyl for 64-bit BARs. >>> >>> You're right so this means its not proper to adjust mmio_total to >>> include conflicting reserved ranges and finally moved all conflicting >>> bars to high_mem_resource as Kevin suggested previously, so i high >>> level, we still need to decrease pci_mem_start to populate more RAM to >>> compensate them as I did, right? >> >> You probably should do both: Prefer moving things beyond 4Gb, >> but if not possible increase the MMIO hole. >> > > I'm trying to figure out a better solution. Perhaps we can allocate > 32-bit bars and 64-bit bars orderly. This may help us bypass those > complicated corner cases. Dealing with 32- and 64-bit BARs separately won't help at all, as there may only be 32-bit ones, or the set of 32-bit ones may already require you to do re-arrangements. Plus, for compatibility reasons (just like physical machines' BIOSes do) avoiding to place MMIO above 4Gb where possible is still a goal. > #1. We don't calculate how much memory should be compensated to add them > to expand something like we though previously. > > #2. Instead, before allocating bars, we just check if reserved device > memory is really conflicting this default region [pci_mem_start, > pci_mem_end] > > #2.1 If not, obviously nothing is changed. > #2.2 If yes, we introduce a new local bool, bar32_allocating, which > indicates if we want to allocate 32-bit bars and 64-bit bars separately. > > So here we should set as true, and we also need to set 'bar64_relocate' > to relocate bars to 64-bit. Doesn't look like the right approach to me. As said before, I think you should allocate BARs _around_ reserved regions (perhaps filling non-aligned areas first, again utilizing that BARs are always a power of 2 in size). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |