On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we need to retrieve the function's arguments. Those arguments are bits of QEMU configuration, as you say, and fw_cfg is extremely inconvenient for fetching them. Whenever the domain or arity of said "mathematical" function changes (we need more arguments, or different kinds of arguments), we have to extend fw_cfg with yet another ad-hoc key or file entry.
The set of arguments going into ACPI tables *is* ad-hoc and arbitrary, there's nothing to do about it. But at least we shouldn't impede the retrieval of said arguments with artificial obstacles, such as half-assedly serializing them over fw_cfg (and not documenting them, naturally). In qemu the entire pool of arguments, current and future, would be at just an arm's length, in immediately consumable form.
I've said the same about the acpi_build_madt() prototype that was proposed for qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/207171/focus=208719.
Thanks, Laszlo