Hi,
Then seabios will still panic. I fail to see how pci-info makes things more user-friendly as you've claimed a few mails back. No doubt about the need to configure the 64bit window size.
We need to fix it not to panic, but we put the user in control since windows size can now come from user.
I'm confused. Why would seabios panic?
It does in case it can't fit the pci bars into the I/O windows. Right now we don't have some fallback mechanism like dropping the device with the largest bar from the list, then try again.
It is the job of the firmware to initialize the hardware. IMO it should work that way on qemu too to mimic real hardware.
That's exactly what we have. However QEMU is the one that knows how hardware is configured (e.g. where's the PCI hole), so we report that to bios.
It was my understanding that the PCI hole size is determined by hardware, and thus it makes sense for QEMU to send this to seabios. (If not the hardware itself, the memory controller configuration, which is effectively the same thing as we wont be adding full emulation of a memory controller to qemu/seabios.) Correct me if I'm wrong.
As I understand it you just need some free address space. For 32bit pci bars this actually is a "hole" in the memory map, i.e. some room below 4G which isn't backed by memory. 64bit pci bars can be pretty much anywhere where they don't conflict with memory (well, in theory, in practice it makes sense to group them in a address space window for a number of reasons).
On piix4 seabios gets the installed low memory from cmos to figure where the free 32bit address space starts so it knows where it can place the pci bars.
On q35 the 32bit pci window is simply hardcoded (same in qemu and seabios), but we can surely change that and make q35 look at the cmos too. Or memory controller config if we'll go emulate that some day.
64bit bars are placed above the installed high memory.
coreboot ressource management doesn't know "pci holes" btw. Instead you'll go register the fixed ressources (io ports, memory) and coreboot goes find non-conflicting places for your pci bars. On q35 machines with 1G of memory it figures there is room between 0x40000000 (end of ram) and 0xb0000000 (start of mmconf xbar) and goes place the pci bars there. Then the linux kernel figures this is outside the window declared via _CRS and goes remap the bars so they are above 0xc0000000.
Also, I don't understand the underlying reason for this patch. If a user asks to start QEMU with a PCI device with a very large BAR, then winxp wont work. But, if a user put a real PCI device with a very large BAR in a real computer then they'd get the same failure. Why is this a qemu/seabios issue - shouldn't the user simply not do this?
Well, qemu/seabios clearly needs some configuration knob for this. On physical hardware there probably would be some bios setup option to enable/disable the 64bit window and to configure the size. We'll need some aequivalent in fw_cfg.
I don't think pci-info is the solution though. For the 32bit window we already have the interfaces needed (lookup low memory in cmos), there is no need for another one. For the 64bit window we should IMO just pass the size wanted to the firmware.
cheers, Gerd