Maybe this wasn't clear, but in (4) the table is generated by *qemu* with the values programmed by the firmware.
Yes. I still don't much like it. I'd think it would be much simpler for qemu to generate the tables once at startup and not have to patch them at runtime. It also introduces an obscure dependency on the ordering of the firmware.
The ordering isn't a big problem I think as it fits the normal order how the firmware boots up: hardware initialization goes first, generating the tables for the guest comes later on.
The mmconf xbar is setup as one of the first things coreboot does, even before romstage, then coreboot does the complete pci initialization using mmconf.
It's not hard to read a value from fw_cfg early on (even in assembler):
outw(FWCFG_MY_EARLY_PORT, PORT_QEMU_CFG_CTL); u8 myval = inb(PORT_QEMU_CFG_DATA);
Well, only if the stuff isn't in a fw_cfg file, which happens to be the case for all new stuff we are adding. Also I'm not sure I can easily make the xbar location a runtime variable in coreboot.
Also, if this needs to be determined before the ram controller is initialized, then I think it's fine to hard code the value (real machines will almost assuredly hardcode as well).
Yea, real machines hardcode that. As mentioned for coreboot this is a compile-time constant (aka #define), which makes sense of course. With firmware generating the acpi tables this works fine, it just uses the #defined value when writing the tables.
With qemu generating the acpi tables we can hardcode it to the same value in both firmware and qemu. Which pretty much implies we can never ever change it in the future without breaking stuff. Thats why I'd like avoid that in the first place.
Making qemu lookup the values in the hardware registers, after the firmware programmed them, has the big advantage that we don't need any new paravirtual interfaces to have firmware and qemu agree on the values ...
cheers, Gerd