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

[Gerd Hoffmann <kraxel@redhat.com>]

On Mo, 2013-08-12 at 18:42 -0400, Kevin O'Connor wrote:
> On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd Hoffmann wrote:
> > We'll need some way to make sure the pmbase (also mmconf xbar) set by
> > the firmware matches the pmbase address filled into the acpi tables by
> > qemu ...
> > 
> > So the options we have are:
> > 
> >   (1) Hardcode the address everywhere.  This is pretty close to the
> >       current state, 0xb000 is hard-coded pretty much everywhere,
> >       basically because older qemu versions had the pmbase register
> >       readonly with 0xb000.  I'd like to move the pmbase somewhere else
> >       long-term, to free the 0xb000-0xbfff window, so I'd like to avoid
> >       that.
> > 
> >   (2) Have qemu pick pmbase/xbar addr.  Doesn't work due to
> >       initialization order issues (especially xbar for coreboot).
> > 
> >   (3) Have firmware pick pmbase/xbar, have fixup instructions for the
> >       addresses in in the loader script, simliar to the fixup
> >       instructions for table-to-table pointers.
> > 
> >   (4) [ new idea by mst ]  Have firmware pick pmbase/xbar, then have
> >       qemu look at the hardware registers programmed by the firmware,
> >       use pmbase/xbar addresses found there there when generating the
> >       tables.
> 
> I don't much like option 3 or 4.
> 
> Although hardcoding (option 1) is ugly, I think that ugliness does not
> justify the complexity of run-time patching (3/4).

Maybe this wasn't clear, but in (4) the table is generated by *qemu*
with the values programmed by the firmware.

> As for option 2 - I don't see why coreboot couldn't read the values
> out of fw_cfg early on for the handful of cases like this.

Because both mmconf xbar and pmbase are special:

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.

pmbase handling depends on southbridge/mainboard code, but it tends to
be setup early (in romstage) too.  On some boards ram detection needs to
fiddle with pmbase registers.

Setting pmbase at runtime looks doable though, even though we might have
to go for a temporary location for the pmbase in romstage, then move it
to the final place requested by qemu later.  But it needs some
qemu-specific tweaks in shared southbridge code though as picking pmbase
at runtime isn't something which happens on real hardware.  I'd like to
avoid that if possible.

cheers,
  Gerd