On Thu, Feb 06, 2014 at 04:40:28PM +0100, Gerd Hoffmann wrote:
On Do, 2014-02-06 at 10:21 -0500, Kevin O'Connor wrote:
On Thu, Feb 06, 2014 at 09:38:15AM +0100, Gerd Hoffmann wrote:
On Mi, 2014-02-05 at 20:04 -0500, Kevin O'Connor wrote:
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?)
qemu will look at the chipset registers programmed by the firmware and fill acpi accordingly. Which reminds me that this only works with qemu 1.8+ where qemu actually generates the acpi tables, so I should update the help text accordingly (raise minimum qemu version from 1.4 to 1.8).
Well, that's backwards.
Sort of, but nevertheless it makes perfect sense IMO. It fits naturally with the firmware initialization order: First setup hardware, then handle bios tables. So the firmware can program the hardware as it pleases, and when it loads the acpi tables from qemu later on they will have the correct addresses filled in. We also don't need any paravirtual interfaces to communicate the addresses between qemu and firmware: Firmware just sets the registers of the emulated hardware.
Doing it the other way around is tricky for initialization order reasons, especially for coreboot. pmbase and mmconf xbar (those are looked up by the qemu acpi table generator) locations are (a) compile time constants and (b) programmed very early at boot time.
Ahh - I vaguely recall discussing this before.
However, I don't think it makes sense for SeaBIOS to have a compile time definition on where to place the mappings. Can't it be pulled from fwcfg?
-Kevin