On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote:
Hi,
To me it makes more sense to just go the direct route and say "please put the 64bit bars at this location" rather than indirect "we might want hotplug $thatmuch memory" and then expect the bios to leave that much room.
Only if the newfeature address is not under bios control. I know that bios is simplistic so all it cares about ATM is pci window, but can't shake the impression that we are better off telling the guest what's going on rather than what it should do.
In particular the issue that was discussed (what to do if pci start is set by host to below ram end) will simply go away if we pass in an incremental value: there will be no invalid configurations.
The "what is going on" might need updates in both qemu and seabios if something new goes on. For example qemu getting support non-contignous memory. The "leave that much address space free above memory" suddenly is ambiguous as there are two (or more) memory blocks above 4g. "please place 64bit pci bars there" continues to work just fine.
Yes but at the cost of overspecifying it. I think it's down to the name: it's called pcimem64-start but it can actually be less than 4G and we need to worry what to do then. Also, 64 doesn't really mean >4G.
So how about "reserve-memory-over-4g"? bios then does 1ull << 32 + reserve-memory-over-4g to figure out how much to skip.
It's not unthinkable. Multiple ECAM regions (for multi-root systems) can make holes in the address space.
Sounds pretty theoretic ...
What? Multiple PCI roots?
That we'll need pass multiple pci windows because of that. I expect we'll need seabios support for the new multi-root hardware anyway, and seabios will probably be aware of the hardware constrains then ...
Also as far I know nobody is working on such a chipset.
I simply wouldn't worry about that today. Designing a interface when you don't know the exact needs for the it has a high chance to go wrong.
Well you were the one that asked about that :)
Also, we just ignore everything above the ioapic, but that's not a must, we could maybe use address space above ioapic.
Any reason why we should that?
32 bit address space is contrained, using it is preferable for 32 bit guests ...
This wouldn't help in the cases I've seen in practice. We have no problems at all to fit in mmio pci bars, even lots of them, they are small enough. We can run out of address space if we have pci devices with larger chunks of memory on them, such as qxl or ivshmem. And these memory bars are too big to fit into any of the small holes above the ioapic.
cheers, Gerd