On Mon, Nov 08, 2010 at 04:35:38PM +1300, Alexey Korolev wrote:
64bit bar allocation
Your patche tries to address this issue. But it breaks PCI-to-PCI
bridge filtering support.
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
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
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.