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

Igor Mammedov imammedo at redhat.com
Tue Oct 15 11:47:23 CEST 2013


On Tue, 15 Oct 2013 12:16:43 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:

> On Tue, Oct 15, 2013 at 11:05:48AM +0200, Igor Mammedov wrote:
> > On Tue, 15 Oct 2013 10:01:01 +0200
> > Gerd Hoffmann <kraxel at redhat.com> 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).
> > > 
> > > 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 ...
> > Michael,
> > 
> > My preference is the same as Gerd's.
> > Though if you NACK this approach, I'm fine with relative to 4g approach
> > as you suggest, the only change I'd like to see in naming is memory
> > reservation to be replaced with pcimem64, i.e. something like:
> >  pcimem64-4gb-offset
> > to reflect value we are actually passing in.
> 
> I'm not going to nack.
Ok, then I'll repost with suggested "pcimem64-minimum-address" but no other
changes.

> 
> > > 
> > > What is the state of the qemu side patches btw?
> > I've them ready but they conflict with you 1Tb in e820 RFC,
> > I can post relevant patches as soon as we agree on this topic.
> > May I pick up your patch and post it along with pcimem64-start patches?
> 
> So for qemu we really need to merge them together with
> memory hotplug I think.  It's not a big patch correct?
> If it's small there's no need to merge just this interface
> first, let's merge it all together.
It's quite independent from memhotplug so I'll just cherry-pick ~3-4 patches
and post them.

> > > 
> > > cheers,
> > >   Gerd
> > > 
> > > 
> > > 
> 




More information about the SeaBIOS mailing list