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

[Michael S. Tsirkin]

On Wed, Aug 07, 2013 at 12:29:32PM +0200, Gerd Hoffmann wrote:
> On 08/07/13 11:50, Michael S. Tsirkin wrote:
> > On Wed, Aug 07, 2013 at 09:29:39AM +0200, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >>>> For whatever we don't know about, why should we assume 64-bit BARs
> >>>> work?  Especially considering it's likely to be pretty old guests.
> >>
> >>> There's no need to assume 64 bit BARs works.
> >>> But I think we can assume guests don't crash.
> >>> What windows does here is very unusual imho,
> >>> guest should just say "I can't use this range
> >>> so I won't" and allocate BARs somewhere else.
> >>
> >> Why windows crashes or what it should do doesn't matter.  We have to
> >> deal with it.
> >>
> >> Today we have a pretty simple logic in seabios:  When we run out of
> >> space in the 32bit pci memory window we'll enable the 64bit window and
> >> try to move 64bit bars there.  So with a usual configuration there is no
> >> 64bit window simply because it isn't needed.  WinXP is happy.  If you
> >> plug in pci devices with large 64bit bars the 64bit window shows up.
> >> So, how about simply keeping that logic?
> >> We can drop the etc/pci-info logic then.
> > 
> > I don't think this is a good idea.
> > 
> > First, windows XP currently crashes if you supply a device with a
> > large BAR.
> > That's not a friendly way to tell user their OS
> > doesn't support the device, not enabling the device is better.
> 
> That logic isn't there today.  seabios will simply panic, before it
> prints anything on the screen, which is even more unfriendly than a blue
> screen.
> And even when "not enabling the device" is implemented:  If that device
> happens to be qxl (one of the few qemu-emulated devices which actually
> can have a large 64bit bar) the user would have a guest without display too.

VFIO also comes to mind - you might need to boot from this device.
bios can also often do the smart thing and enable boot devices,
disabling others.

But anyway, with latest QEMU this is user's mistake:
user specifies the values for pci-info and
user also specified set of devices inconsistent with that.
So management which knows exactly which version of windows is installed
can create the correct configuration.

> > Second, current logic has *no chance* to support hotplug
> > of devices with large BARs. We will put work arounds for
> > XP in place to just disable 64 bit hole,
> > but for example with windows 7, 32 and 64 bit versions
> > both support a 64 bit hole but different max sizes,
> > and there's no easy way to distinguish between them.
> 
> --verbose please (but see also below).

msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).asp

Generally, windows tends to crash when CRS resources exceed the supported limits
of physical memory (sometimes with weird off by one errors,
e.g. win7 32 bit seems to survive with a 36 bit pci hole even though
this means the max address is 2^37-1 which it can't address).

> > Third, there are good reasons for pci-info, and
> > windows bugs don't outweight them.
> > In particular, there's duplicated logic in bios and QEMU,
> > if you change QEMU to be closer to real hardware, kaboom.
> 
> --verbose please.  Which logic is duplicated?

The one setting the PCI hole addresses :)

> > Last, it's a maintainance problem that we need
> > drivers for all chipsets open-coded in BIOS.
> > One suggestion we had is moving completely away
> > and supplying some bytecode for what's left of chipset
> > configuration (e.g. memcfg) to seabios.
> 
> Sorry, but I fail to see the problem.  There isn't that much
> chipset-specific code in seabios, and it rarely needs changes.  Adding a
> bytecode interpreter to be able to rip it out sounds like overkill to me.

Possibly, though I shouldn't really have said bytecode - more
a set of address/data pairs to write into config space
(if you like, it can be a loader extension).
But let's discuss this separately.

> >> We probably also need some knob asking seabios to enable the 64bit
> >> window unconditionally, so we have some address space for hotplugging
> >> pci devices with large bars.
> > 
> > I think you got it wrong. The common case is enabling
> > the 64 bit window. The default should be to enable it,
> > with a knob to disable.
> 
> Why enable by default?  I would be conservative here.  I have yet to see
> real hardware with a 64bit pci window.
> Things which are rare or don't
> exist on real hardware have a higher chance to trigger guest bugs.

In fact, it's up to QEMU whether to enable it by default.
Yes we could be even more aggressive, and tweak
398489018183d613306ab022653552247d93919f
to make the default 0 and not 2G.

If we do this, we can take the time with designing the
proper fix for winXP - this just shows
that pci-info is the right approach.


> > We must also supply the 64 bit window size as
> > the limits differ between windows guests.
> > That's exactly the etc/pci-info logic.
> 
> pci-info does more than just the 64bit window size.
> 
> cheers,
>   Gerd

Yes.  It does exactly what's needed to make sure PCI windows
match the addresses that hardware listens on.
Selecting the size is just one aspect of it but it's
covered too, and this way management can make the decision.