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

Michael S. Tsirkin mst at redhat.com
Thu Aug 8 07:42:05 CEST 2013


On Wed, Aug 07, 2013 at 07:58:18PM -0400, Kevin O'Connor wrote:
> On Wed, Aug 07, 2013 at 05:53:12PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Aug 07, 2013 at 04:21:44PM +0200, Gerd Hoffmann wrote:
> > > On 08/07/13 14:35, Michael S. Tsirkin wrote:
> > > > On Wed, Aug 07, 2013 at 02:15:14PM +0200, Gerd Hoffmann wrote:
> > > >> qemu doesn't error out though, so what is the point?
> > > > 
> > > > The point is management can set the size according
> > > > to the type of guest that will be installed.
> > > > You can misconfigure qemu in a variety of ways
> > > > and not all of them cause it to error out.
> > > 
> > > 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?

Question is, what to do if we can't fit all BARs into the range
supplied by QEMU?

> > > > And then it will have exactly the same issue if you misconfigure it.
> > > > The 64bit hole size is the only thing that crashes old windows.
> > > > So if you want that, then what's your problem with pci-info really?
> > > 
> > > pci-info it has stuff which shouldn't be there IMO.
> > > 
> > > 
> > > 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.

This is certainly true for PIIX. It's more complicated for Q35
since the hole start address is configurable by firmware.
Gerd refers to mch_setup in src/pciinit.c

> 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?
> 
> -Kevin

Sure. But if we can find a simple low risk way to make
winXP not allocate resources rather than crash,
that's a bit nicer, isn't it?

-- 
MST



More information about the SeaBIOS mailing list