OSDev.org

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!

How big is QEMU's ECAM region?

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

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?

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.

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.

That pointer is very helpful, thank you!