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