Re: [v7][RFC][PATCH 05/13] hvmloader/mmio: reconcile guest mmio with reserved device memory

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2014/10/29 17:08, Jan Beulich wrote:
>>>> On 29.10.14 at 08:03, <tiejun.chen@intel.com> wrote:
>> On 2014/10/28 17:56, Jan Beulich wrote:
>>>>>> On 28.10.14 at 08:11, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/27 17:56, Jan Beulich wrote:
>>>>>>>> On 27.10.14 at 08:12, <tiejun.chen@intel.com> wrote:
>>>>>> On 2014/10/24 22:42, Jan Beulich wrote:
>>>>>>>>>> On 24.10.14 at 09:34, <tiejun.chen@intel.com> wrote:
>>>>>> Additionally, actually there are some original codes just following my
>>>>>> codes:
>>>>>>
>>>>>>             if ( need_skip_rmrr )
>>>>>>             {
>>>>>> 		...
>>>>>>             }
>>>>>>
>>>>>> 	base += bar_sz;
>>>>>>
>>>>>>             if ( (base < resource->base) || (base > resource->max) )
>>>>>>             {
>>>>>>                 printf("pci dev %02x:%x bar %02x size "PRIllx": no space for "
>>>>>>                        "resource!\n", devfn>>3, devfn&7, bar_reg,
>>>>>>                        PRIllx_arg(bar_sz));
>>>>>>                 continue;
>>>>>>             }
>>>>>>
>>>>>> This can guarantee we don't overwhelm the previous mmio range.
>>>>>
>>>>> Resulting in the BAR not getting a value assigned afaict. Certainly
>>>>> not what we want as a side effect of your changes.
>>>>
>>>> I don't understand what a side effect is. I just to try to make sure BAR
>>>> space skip any conflict range but they are still in these resource ranges.
>>>
>>> A side effect is an effect you don't primarily intend with your change
>>> (or more generally, with any particular operation). In the case here,
>>> a BAR that previously got a value assigned may not anymore with
>>> your change in place. An acceptable effect of your change would be
>>> if the value it gets assigned is now different, but not assigning a value
>>> at all is not acceptable.
>>
>> As I understand that value just need to align with BAR and size. Then
>> any range should be fine. Here I think its not necessary to consider any
>> space restriction, i.e, some device may just access under 4G.
>
> No. The code determining where to put the lower boundary of the
> MMIO range doesn't (with your present patch) consider the regions
> the actual assignment code now skips. Hence the lower boundary
> may not be low enough to accommodate all BARs.

Right, so maybe before any mmio allocation, we can expand mmio resource 
to own sufficient space covering RMRR and all BARs.

Thanks
Tiejun

>
> Jan
>
>
>