On Tue, Oct 15, 2013 at 11:05:48AM +0200, Igor Mammedov wrote: > On Tue, 15 Oct 2013 10:01:01 +0200 > Gerd Hoffmann <kra...@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. > > > > 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. > > > > cheers, > > Gerd > > > > > >
