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