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