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