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 > _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios