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