On Tue, 15 Oct 2013 12:16:43 +0300 "Michael S. Tsirkin" <m...@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 <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. 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 > > > > > > > > > >