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

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

On Tue, Oct 15, 2013 at 10:01:01AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > 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.
> 
> We are reaching the point where it becomes pointless bikeshedding ...
> 
> I want a interface which is clearly defined and which doesn't break if
> the way we use the address space above 4g changes (hotplug,
> non-contignous memory, whatever).  So make it depend on the memory
> deployed isn't a clever idea.
> 
> So at the end of the day it comes down to specify an address, either
> relative to 4g (your reserve-memory-over-4g suggestion) or relative to
> zero (Igors pcimem64-start patch).  Both will do the job.  In both cases
> the bios has to check it has no conflicts with known ram regions (i.e.
> compare against 1<<32 + RamSizeAbove4G).

Actually it doesn't: bios doesn't use RAM above 4G value.
It passes it to guest but ignores it itself.
So you can likely boot guest and let it figure it out.


> 
> I personally don't see the point in having the address relative to 4g
> and prefer the pcimem64-start approach.  We could rename it to
> pcimem64-minimum-address to make more clear this is about keeping some
> space free rather than specifyng a fixed address where the 64bit pci
> bars should be mapped to.  But at the end of the day I don't care too
> much, how we are going to name the baby is just a matter of taste and
> not really critical for the interface ...

I agree with this last claim.
Finding a nice name

> What is the state of the qemu side patches btw?
> 
> cheers,
>   Gerd
>