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