On 05/25/11 06:33, Isaku Yamahata wrote:
The patch doesn't check any overflows. And it assumes that BAR assignment is always possible. However it isn't true. Some people complained about it before, so I added overflow check.
Indeed, there is no error handling at all yet.
Some devices have very huge BAR like 1G, 2G... For example, qemu ivshmem or device-assignment of home-made device. Those huge BAR would be unallocated with warning. (Usually such huge BAR is 64bit, and we don't allocate 64bit BAR to 4G+ area at the moment.)
A number of possible improvements I can think of:
(1) Figure which devices are needed to boot. That list should include VGA, storage devices, NICs (with ROM), maybe all devices with a ROM. Anything else? (2) For devices which are not needed to boot we can: (a) Map 64bit bars above 4G. (b) Skip device altogether. (3) All bridges get some minimum amount of io and memory space. This is needed for bridges which support hotplug only.
Not sure it is worth trying to map 64bit bars above 4G as we can do that only for devices not needed to boot (otherwise we'll have trouble driving the device), and for those devices we can leave that job to the guest OS anyway ...
+static struct pci_bus { +} busses[32];
Statically allocated? Should we be go for three pass by splitting the first pass into two?
Well, there actually is a bus enumeration pass already, so switching to dynamic allocation should be easy.
cheers, Gerd