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