But anyway, with latest QEMU this is user's
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
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
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.
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.