Re: [Qemu-devel] [SeaBIOS] [PATCH] acpi: hide 64-bit PCI hole for Windows XP

[Gerd Hoffmann <kraxel@redhat.com>]

> > Maybe this wasn't clear, but in (4) the table is generated by *qemu*
> > with the values programmed by the firmware.
> 
> Yes.  I still don't much like it.  I'd think it would be much simpler
> for qemu to generate the tables once at startup and not have to patch
> them at runtime.  It also introduces an obscure dependency on the
> ordering of the firmware.

The ordering isn't a big problem I think as it fits the normal order how
the firmware boots up: hardware initialization goes first, generating
the tables for the guest comes later on.

> > The mmconf xbar is setup as one of the first things coreboot does, even
> > before romstage, then coreboot does the complete pci initialization
> > using mmconf.
> 
> It's not hard to read a value from fw_cfg early on (even in
> assembler):
> 
> outw(FWCFG_MY_EARLY_PORT, PORT_QEMU_CFG_CTL);
> u8 myval = inb(PORT_QEMU_CFG_DATA);

Well, only if the stuff isn't in a fw_cfg file, which happens to be the
case for all new stuff we are adding.  Also I'm not sure I can easily
make the xbar location a runtime variable in coreboot.

> Also, if this needs to be determined before the ram controller is
> initialized, then I think it's fine to hard code the value (real
> machines will almost assuredly hardcode as well).

Yea, real machines hardcode that.  As mentioned for coreboot this is a
compile-time constant (aka #define), which makes sense of course.  With
firmware generating the acpi tables this works fine, it just uses the
#defined value when writing the tables.

With qemu generating the acpi tables we can hardcode it to the same
value in both firmware and qemu.  Which pretty much implies we can never
ever change it in the future without breaking stuff.  Thats why I'd like
avoid that in the first place.

Making qemu lookup the values in the hardware registers, after the
firmware programmed them, has the big advantage that we don't need any
new paravirtual interfaces to have firmware and qemu agree on the
values ...

cheers,
  Gerd