From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: QEMU PCI subsystem: what code is responsible for making accesses to non-mapped addresses read as -1?
Date: Sat, 20 Mar 2021 14:58:58 -0400 [thread overview]
Message-ID: <20210320144325-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAFEAcA_M4zK1aLdO2QdOUgNROTLdHUwLHnCKoUT1BpTcF-cTMw@mail.gmail.com>
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
next prev parent reply other threads:[~2021-03-20 19:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 12:35 QEMU PCI subsystem: what code is responsible for making accesses to non-mapped addresses read as -1? Peter Maydell
2021-03-19 14:14 ` Philippe Mathieu-Daudé
2021-03-19 21:13 ` Laszlo Ersek
2021-03-20 18:58 ` Michael S. Tsirkin [this message]
2021-03-20 20:40 ` Peter Maydell
2021-03-20 21:50 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210320144325-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).