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