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

[Philippe Mathieu-Daudé]

On 12/17/19 7:52 PM, Alex Williamson wrote:
> On Tue, 17 Dec 2019 19:31:41 +0100
> Paolo Bonzini <address@hidden> wrote:
>
> > On 17/12/19 19:17, Peter Maydell wrote:
> > > On Tue, 17 Dec 2019 at 16:57, Richard Henderson
> > > <address@hidden> wrote:
> > > > On 12/17/19 1:58 AM, Christophe de Dinechin wrote:
> > > > >   
> > > > > > On 17 Dec 2019, at 11:51, Paolo Bonzini <address@hidden> 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.