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.
On Wed, Aug 07, 2013 at 04:21:44PM +0200, Gerd
On 08/07/13 14:35, Michael S. Tsirkin wrote:
On Wed, Aug 07, 2013 at 02:15:14PM +0200, Gerd
> 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
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?
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?