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
