On 6 June 2018 at 21:23, Paul Burton <paul.bur...@mips.com> wrote: > Hi Peter, > > On Mon, Jun 04, 2018 at 11:29:47AM +0100, Peter Maydell wrote: >> Hi; I was looking at the code for this PCI controller as >> part of identifying RAM memory regions that don't migrate >> their contents, and this looks kind of odd. Can you explain >> why this is using a RAM region for the PCI bus's IO memory >> space? None of our other PCI controller models do this, so >> I suspect this is a bug. (The effect would be that PCI IO >> accesses to addresses which don't have a PCI BAR mapped there >> will behave as reads-as-written, which seems pretty unlikely >> to be what the hardware does.) >> >> What is the intended semantics for PCI IO accesses with this >> controller? (It seems to only be used with the MIPS boston >> board model.)
> The controller here simply doesn't support I/O accesses, and the dummy > region is there to prevent the rest of QEMU's PCI code & device > emulation from needing to care about that fact. The region is never > mapped into the system memory and so software running on the emulated > system has no way to access it. Right, I wondered if that was the case. The region should not be RAM, then, it should be a dummy does-nothing region. I'll put a patch together at some point. thanks -- PMM