On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote:
On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek
This was how I interpreted our discussion with
L: Shouldn't qemu & OVMF agree on GPE0?
J: Why? Anyway, OVMF should be correct, because all ACPI registers are
in one tight bunch, starting from 0x400.
L: None of those two characteristics (1: "0x400", 2: "one tight
are required by the spec. For proof, see what SeaBIOS does: 1: it
doesn't use 0x400 as base, 2: GPE0 is not even above the base.
This code was written to the PIIX4 datasheet. According to the
datasheet, if you change PMBA, it changes the GPE blk too.
It sounds like QEMU does not emulate this, and hardcodes the GPE blk.
Yes. QEMU does not really implement PIIX4 though. It implements PIIX3 +
PM from PIIX4 (but with a functionality that is not present in original
spec like pci/cpu hotplug) + other differences that firmware had to take
into account. For instance event if QEMU will implement PMBA, OVMF would
not be able to configure it to the value 0x400 since QEMU hardcodes
another PV device there.
Regarding a solution, such as communicating the
address in fw_cfg,
that could work. OVMF has plans to add fw_cfg support.
Can it check that it runs over QEMU and use QEMU's values? No need for
to my original question: currently OVMF and qemu disagree
wrt. GPE0. Which one should I try to modify so that they agree?
It does seem like qemu could be changed, does it? It would require a
simultaneous fix of qemu & seabios. But, if qemu could be changed,
could it be made to match the PIIX4 datasheet?
We try not to change QEMU in non backwards compatible way. We can
implement PMBA and start using address there if FW writes into it,
but, as I noted before, OVMF will have to be changed anyways since 0x400
address is already occupied and pci/cpu/memory hotplug/unplug
functionality uses additional IO space not documented by PIIX4 spec.
It would be better for OVMF to treat QEMU like separate platform, that
behave almost, but not exactly like, real HW.