Re: [PATCH] memory: Do not allow subregion out of the parent region range

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 12/17/19 7:52 PM, Alex Williamson wrote:
> On Tue, 17 Dec 2019 19:31:41 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 17/12/19 19:17, Peter Maydell wrote:
>>> On Tue, 17 Dec 2019 at 16:57, Richard Henderson
>>> <richard.henderson@linaro.org> wrote:
>>>>
>>>> On 12/17/19 1:58 AM, Christophe de Dinechin wrote:
>>>>>
>>>>>   
>>>>>> On 17 Dec 2019, at 11:51, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>>> Yes, the idea is that you could have for one version of the device
>>>>>>
>>>>>>    parent 0x000-0x7ff
>>>>>>      stuff 0x000-0x3ff
>>>>>>      morestuff 0x400-0x7ff
>>>>>>
>>>>>> and for another
>>>>>>
>>>>>>    parent 0x000-0x3ff
>>>>>>      stuff 0x000-0x3ff
>>>>>>      morestuff 0x400-0x7ff
>>>>>>
>>>>>> where parent is the BAR, and you can share the code to generate the tree
>>>>>> underneath parent.
>>>>>
>>>>> I can see why you would have code reuse reasons to do that,
>>>>> but frankly it looks buggy and confusing. In the rare cases
>>>>> where this is indented, maybe add a flag making it explicit?
>>>>
>>>> The guest OS is programming the BAR, producing a configuration that, while it
>>>> doesn't make sense, is also legal per PCI.  QEMU cannot abort for this
>>>> configuration.
>>>
>>> Does guest programming of the PCI BAR size actually change the size
>>> of the 'parent' region, or does it just result in the creation
>>> of an appropriately sized alias into 'parent' ?
>>
>> Resizable BARs are not handled by the PCI host bridge but rather from
>> the device itself, so the device is free to handle them either way.
> 
> More specifically, it's the responsibility of drivers within the guest
> to resize the parent bridge aperture to make the extent of the BAR
> accessible.  This does seem like an interesting way to implement a
> resizable BAR in QEMU though.  Thanks,

This is something I'm thinking about since some time, as I observed this 
behavior in 3 different MIPS boards with different northbridge chipset 
(Malta with the GT64120, Fuloong2E with the Bonito).
The firmware sets one layout, Linux (or other) reinit & reorder all the 
memory layout. I guess Mark hit the same issue with his sparc64 based 
boards.