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

[Gerd Hoffmann]

  Hi,

>>> Then seabios will still panic.  I fail to see how pci-info makes things
>>> more user-friendly as you've claimed a few mails back.
>>> No doubt about the need to configure the 64bit window size.
>>
>> We need to fix it not to panic, but we put the user in control since
>> windows size can now come from user.
> 
> I'm confused.  Why would seabios panic?

It does in case it can't fit the pci bars into the I/O windows.  Right
now we don't have some fallback mechanism like dropping the device with
the largest bar from the list, then try again.

>>> It is the job of the firmware to initialize the hardware.  IMO it should
>>> work that way on qemu too to mimic real hardware.
>>
>> That's exactly what we have. However QEMU is the one that knows
>> how hardware is configured (e.g. where's the
>> PCI hole), so we report that to bios.
> 
> It was my understanding that the PCI hole size is determined by
> hardware, and thus it makes sense for QEMU to send this to seabios.
> (If not the hardware itself, the memory controller configuration,
> which is effectively the same thing as we wont be adding full
> emulation of a memory controller to qemu/seabios.)  Correct me if I'm
> wrong.

As I understand it you just need some free address space.  For 32bit pci
bars this actually is a "hole" in the memory map, i.e. some room below
4G which isn't backed by memory.  64bit pci bars can be pretty much
anywhere where they don't conflict with memory (well, in theory, in
practice it makes sense to group them in a address space window for a
number of reasons).

On piix4 seabios gets the installed low memory from cmos to figure where
the free 32bit address space starts so it knows where it can place the
pci bars.

On q35 the 32bit pci window is simply hardcoded (same in qemu and
seabios), but we can surely change that and make q35 look at the cmos
too.  Or memory controller config if we'll go emulate that some day.

64bit bars are placed above the installed high memory.

coreboot ressource management doesn't know "pci holes" btw.  Instead
you'll go register the fixed ressources (io ports, memory) and coreboot
goes find non-conflicting places for your pci bars.  On q35 machines
with 1G of memory it figures there is room between 0x40000000 (end of
ram) and 0xb0000000 (start of mmconf xbar) and goes place the pci bars
there.  Then the linux kernel figures this is outside the window
declared via _CRS and goes remap the bars so they are above 0xc0000000.

> Also, I don't understand the underlying reason for this patch.  If a
> user asks to start QEMU with a PCI device with a very large BAR, then
> winxp wont work.  But, if a user put a real PCI device with a very
> large BAR in a real computer then they'd get the same failure.  Why is
> this a qemu/seabios issue - shouldn't the user simply not do this?

Well, qemu/seabios clearly needs some configuration knob for this.  On
physical hardware there probably would be some bios setup option to
enable/disable the 64bit window and to configure the size.  We'll need
some aequivalent in fw_cfg.

I don't think pci-info is the solution though.  For the 32bit window we
already have the interfaces needed (lookup low memory in cmos), there is
no need for another one.  For the 64bit window we should IMO just pass
the size wanted to the firmware.

cheers,
  Gerd