On 03/19/21 15:14, Philippe Mathieu-Daudé wrote: > On 3/19/21 1:35 PM, Peter Maydell wrote: >> I'm looking at a bug reported against the QEMU arm virt board's pci-gpex >> PCI controller: https://bugs.launchpad.net/qemu/+bug/1918917 >> where an attempt to write to an address within the PCI IO window >> where the guest hasn't mapped a BAR causes a CPU exception rather than >> (what I believe is) the PCI-required behaviour of writes-ignored, reads >> return -1. >> >> What in the QEMU PCI code is responsible for giving the PCI-spec >> behaviour for accesses to the PCI IO and memory windows where there >> is no BAR? I was expecting the generic PCI code to map a background >> memory region over the whole window to do this, but it looks like it >> doesn't... > > Indeed, this is something I noticed in my generic AddressSpace > cleanup series. > > Currently it is (incorrectly?) done locally by each pci-host > implementation, some register the regions behaving as RAZ/WI, > some don't. >
Related discussions from the past: (1) [Qemu-devel] [PATCH] exec: fix regression by making system-memory region https://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00142.html (Commits: a53ae8e934cd ('hw/pci: partially handle pci master abort', 2013-10-14) 818f86b88394 ('exec: limit system memory size', 2013-11-04) 0fbf50b6ec12 ('Revert "hw/pci: partially handle pci master abort"', 2013-11-10) ef9e455d645b ('Revert "exec: limit system memory size"', 2013-11-10) ) (2) [Qemu-devel] [PATCH] memory region: check the old.mmio.read status https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01391.html The last two messages in that thread appear particularly relevant: - https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01524.html - https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01525.html Assuming I'm not completely confused, my take-away is that it does belong in each pci-host device model (or maybe into an extracted, parent device model). Namely, Peter said in the last message linked above that whether an unmapped access would cause a CPU fault was the function of two things: - whether the CPU supported bus faults architecturally, - whether the bus in an SoC or board reported unmapped accesses to the CPU as bus faults. For the case where the first question was answered with "yes" but the second was answered with "no", "adding a suitable io accessor to the relevant container MR" was suggested -- and that's what the pci-host device models do, at the moment, IIUC. *Where* this unassigned IO MR should be implemented is unclear: - The 2nd variable above is board/SoC dependent, so does the unassigned IO "catch" belong in board code? - Or else, because the PCI spec is board-independent, does it belong with some common pci-host code? Personally, I'd add it to the pci-gpex controller; that would fix the symptom, satisfy the generic requirement (a function of two variables, see above), and come with no risk of regressions, for other boards / PCI host controllers. Thanks Laszlo
