On 27/10/25 14:26, Peter Maydell wrote:
On Mon, 27 Oct 2025 at 13:12, Alex Bennée <[email protected]> wrote:
Philippe Mathieu-Daudé <[email protected]> writes:
Do not log unassigned MMIO accesses as I/O ones:
expose unassigned_mem_ops then use it instead of
unassigned_io_ops.
But why? Is it because ioport.c is a x86 io thing?
There is a behaviour difference: unassigned_mem_ops
will fault (because of unassigned_mem_accepts()),
but unassigned_io_ops will be "reads as -1, writes
are ignored". This patch series doesn't mention any
intention of introducing a behaviour difference, so
I suspect this is not intended...
Oops... Good catch.
There are a couple of different but related concepts
here that we need to keep straight:
(1) x86 I/O ops, which are different CPU instructions
that talk to a different memory-space than MMIO
accesses. In QEMU we model these as accesses to the
address_space_io AddressSpace. I believe no other
target CPU has an equivalent to this.
This is also my understanding.
(2) PCI "I/O" BARs. PCI devices can have both MMIO
and IO BARs. A PCI controller on x86 maps IO BARs
into the IO space, I think. On non-x86 the IO BARs
typically appear in a different window for MMIO
accesses. Behaviour of PCI I/O accesses to unimplemented
regions is probably defined by the PCI spec somewhere.
Behaviour of PCI accesses to unimplemented MMIO
window areas is I think technically left unspecified
by the PCI standard, but "write ignore/read -1" is
what x86 does and what most software expects, so
hardware that implements something else is making
its life unnecessarily difficult.
Right, this is what I'd like to unify, ...
I suspect we entangle the PCI IO BAR concept and
implementation a bit more with the x86 I/O ops
implementation than we ideally ought to.
... to disentangle that.
