[SeaBIOS] synching GPE0_BLK between OVMF and qemu

Gleb Natapov gleb at redhat.com
Sun Apr 29 10:51:57 CEST 2012

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


More information about the SeaBIOS mailing list