On Sat, Apr 28, 2012 at 06:17:24PM -0700, Jordan Justen wrote:
On Sat, Apr 28, 2012 at 00:08, Gleb Natapov
> 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,
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