On Sat, Apr 28, 2012 at 06:17:24PM -0700, Jordan Justen wrote:
On Sat, Apr 28, 2012 at 00:08, Gleb Natapov gleb@redhat.com wrote:
On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote:
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,
Actually this is incorrect. QEMU implements PMBA and Seabios sets it to 0xb000. Sorry about the confusion.
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.
The "pci/cpu/memory hotplug/unplug functionality" is also using hard coded addresses in the 0x400 range?
No, the hard coded addresses at 0x400 range are used for FW debug. There are four of them 0x400/0x401 used to print panic message on stderr and exit qemu process, now they do nothing but qemu still registers them. 0x402/0x403 print character to stderr if qemu is compiled with DEBUG_BIOS, but ports are registered even if DEBUG_BIOS is not defined.
hotplug/unplug uses addresses 0xae00 and above.
And, 0xb000 would be the recommended PM base address?
Yes. QEMU splits PM and GPE address spaces though. GPE starts at 0xafe0 and is hardcoded. I do not see the way to move it to PMBA + offset and stay backwards compatible (at least not without adding new fw_cfg value, but what would be the advantage).
It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW.
Yes, it does seem like that will be required here.
Yes, since we do want to support functionality that does not exist in PIIX4 spec.
-- Gleb.
-
Gleb Natapov