On Wed, Aug 07, 2013 at 02:15:14PM +0200, Gerd Hoffmann wrote:
Hi,
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.
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.
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 :)
That wasn't duplicated before you've added pci-info.
It was always duplicated. With pci-info it's *not* duplicated anymore: qemu is the single source of info.
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.
Isn't going to fly for coreboot. Initialization of real hardware doesn't work that way, and on coreboot qemu support shares the piix4/ich9 setup code with real mainboards.
Good to know.
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.
This only proves that you can fix the bug introduced by adding pci-info.
Current seabios which completely ignores pci-info works equally well with WinXP.
It doesn't really, and the issue is not WinXP.
Here's a bug, it's easy to reproduce: 1. boot qemu with existing seabios, linux guest 2. add device with large BAR by hotplug (e.g. ivshmem)
Actual result: device isn't allocated a BAR and does not work Expected result device is allocated a 64 bit BAR and works
So the "works just fine" is really only "works for me".
Yes, broken guests seem to be common, so we should be conservative with out defaults, and let management control what happens.
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.
seabios handles this just fine today.
Only because qemu and seabios have identical code for PCI window. But that code has no basis in reality, if we fix QEMU to be closer to real hardware it will break.
The only missing bit is some way to request seabios add a 64bit window (of a certain size) unconditionally, so it is there even in case it isn't needed for the devices present at boot time. A simple etc/pci-64bit-size integer would do the job.
cheers, Gerd
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?