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 >