Hi,
Hi. The current BAR allocation doesn't check overflow and some patches are floating around which aren't merged yet. There are several issues.
- overflow check This should be fixed. Some patches are proposed. None hasn't been merged yet. Your patch also addresses this issue. http://www.seabios.org/pipermail/seabios/2010-July/000794.html http://www.seabios.org/pipermail/seabios/2010-October/001089.html
Right. It would be great if the fix get included in seabios/qemu.
Update: I've seen today's message from Kevin. He is going to merge your patch. So it will be good news for us.
Hmm, it is quite possible, as we don't know a lot about seabios PCI-to-PCI bridge filtering support. Just out of curiosity: what is the issue?
If the BAR size is huge (or there are too many BARs), the bar can't be allocated under 4G. So several persons want seabios to allocate such BARs at >4GB area complaining that OS can't use BARs that seabios didn't assigned.
Others think such BAR can be left unallocated. Seabios role is to setup minimal basic environment for bootloader to boot OS, 64bit bar allocation is beyond it's role. bootloader/rombios usually doesn't handle BARs that is allocated beyond 4GB, and Modern OSes can re-arrange PCI bar allocation itself. So 64bit bar allocation support wouldn't be needed.
I'm not sure if there is enough demand to support 64bit BAR allocation and if Kevin will accept it or not. Consensus is needed. What OS are you using?
For us >4GB allocation is welcome but not critical, because we mainly use Linux versions 2.6.18 and newer. We've tested the seabios without assignment of the regions which do not fit in first 32bit and it appears to work fine. So for us 64bit bar allocation support wouldn't be needed.
It is possible that people will use an ancient version of Linux, but the probability of this event is very low.
Thanks, Alexey
On Mon, Nov 08, 2010 at 04:35:38PM +1300, Alexey Korolev wrote:
Hmm, it is quite possible, as we don't know a lot about seabios PCI-to-PCI bridge filtering support. Just out of curiosity: what is the issue?
It's pci_bios_init_device_bridge() in pciinit.c. The function touches pci_bios_io_addr, pci_bios_mem_addr, and pci_bios_prefmem_addr. So we need to modify, not only pci_bios_allocate_region(), but also pci_bios_init_device_bridge().
The function programs the P2P bridge to forward IO/memory access on primary pci bus to secondary pci bus. It needs to be aware of 64bit BAR allocation.
If the BAR size is huge (or there are too many BARs), the bar can't be allocated under 4G. So several persons want seabios to allocate such BARs at >4GB area complaining that OS can't use BARs that seabios didn't assigned.
Others think such BAR can be left unallocated. Seabios role is to setup minimal basic environment for bootloader to boot OS, 64bit bar allocation is beyond it's role. bootloader/rombios usually doesn't handle BARs that is allocated beyond 4GB, and Modern OSes can re-arrange PCI bar allocation itself. So 64bit bar allocation support wouldn't be needed.
I'm not sure if there is enough demand to support 64bit BAR allocation and if Kevin will accept it or not. Consensus is needed. What OS are you using?
For us >4GB allocation is welcome but not critical, because we mainly use Linux versions 2.6.18 and newer. We've tested the seabios without assignment of the regions which do not fit in first 32bit and it appears to work fine. So for us 64bit bar allocation support wouldn't be needed.
It is possible that people will use an ancient version of Linux, but the probability of this event is very low.
My position is same to yours. Welcome, but not critical. So the issue is, who will finish it.
-
Alexey Korolev -
Isaku Yamahata