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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 27/10/25 14:26, Peter Maydell wrote:
> 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...

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.