Re: [Xen-devel] [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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