Re: [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator

["Michael S. Tsirkin" <mst@redhat.com>]

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
>