Accessing nonexisting PCIe Devices in QEMU

[reloc0]

Hello all,

i have a qemu-system-aarch64 set up with some pci devices added to it. I mapped the ECAM address and try to poke around scanning the PCIe Bus for devices. So i found something curious.

On real hardware when accessing a BUS/DEV/FUNC that does not exist like in no device there and read the DIDVID register at offset 0, the result is a 0xFFFFFFF but in this case with qemu it's 0x00000000 . I have never seen that in actual hardware and was astonished to find a lot more devices than anticipated through this.

While I can just check for 0xFFFFFFFF AND 0x00000000 in the future for non-present device I'd like to understand if that is just a bug in qemu or if it really happens to be 0 and I just never had hardware that implemented it like that, or if it's a specialty with ecam in qemu aarch64 ...

Thanks in advance for your answers. If someone has already asked this and I just didn't have enough google luck, please hint me to the right place.

Best regards!

[Octocontrabass]

How big is QEMU's ECAM region?

[reloc0]

Reported size in info mtree is 0xFFFFFFF so 256M, seems like a full segment.

[Octocontrabass]

What size is reported in the DTB or ACPI tables you're using?

Are you sure you're calculating the correct offsets into the ECAM region?

[reloc0]

The size of 256MB is taken form

qemu-monitor-command info qtree

and I see the a few bridges, ethernet card and NVME there. The data aligns with

qemu-monitor-command info pci

thus i'm relatively sure about the offsets and the calculation.

[Octocontrabass]

QEMU is supposed to return 0xFFFFFFFF when you read a nonexistent vendor/device ID register, so either there's a bug in your copy of QEMU or there's a bug in your code.

You might want to double-check that you're actually reading from the correct address when you read an unexpected 0.

[reloc0]

That pointer is very helpful, thank you!