Re: [PATCH 0/6] hw: Log unassigned MMIO accesses with unassigned_mem_ops

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 27 Oct 2025 at 13:12, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Philippe Mathieu-Daudé <philmd@linaro.org> 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...

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.

(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.

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.

-- PMM