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

[Michael S. Tsirkin]

On Fri, Mar 19, 2021 at 12:35:31PM +0000, 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...
> 
> thanks
> -- PMM

As far as I know, at the PCI level what happens is Master Abort
on PCI/PCI-X and Unsupported Request on Express.
PCI spec says:
        The host bus bridge, in PC compatible systems, must return all 1's on a 
read transaction and
        discard data on a write transaction when terminated with Master-Abort.

We thus implement this per host e.g. on pc compatible systems by
calling pc_pci_as_mapping_init.

A note aside:

PCI Express spec has this weird text:

Read Data Values with UR Completion Status
        Some system configuration software depends on reading a data value of 
all 1’s when a Configuration
        Read Request is terminated as an Unsupported Request, particularly when 
probing to determine the
        existence of a device in the system. A Root Complex intended for use 
with software that depends
        on a read-data value of all 1’s must synthesize this value when UR 
Completion Status is returned for
        a Configuration Read Request.

the title says "Read Data" while the text says "Configuration Read".
Can't say whether that is intentional.

-- 
MST