Re: QEMU PCI subsystem: what code is responsible for making accesses to non-mapped addresses read as -1?

[Laszlo Ersek]

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