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

[Alex Williamson <alex.williamson@redhat.com>]

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,

Alex