qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G suppor


From: M. Warner Losh
Subject: Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
Date: Fri, 01 Feb 2008 09:09:00 -0700 (MST)

In message: <address@hidden>
            Robert William Fuller <address@hidden> writes:
: Avi Kivity wrote:
: > Anthony Liguori wrote:
: >> Fabrice Bellard wrote:
: >>> Anthony Liguori wrote:
: >>>> +    /* above 4giga memory allocation */
: >>>> +    if (above_4g_mem_size > 0) {
: >>>> +        ram_addr = qemu_ram_alloc(above_4g_mem_size);
: >>>> +        cpu_register_physical_memory(0x100000000, 
: >>>> above_4g_mem_size, ram_addr);
: >>>> +    }
: >>>> +
: >>>
: >>> Why do you need this ? All the RAM can be registered with a single 
: >>> call.  I fear you need to do that because of KVM RAM handling 
: >>> limitations.
: >>
: >> On the x86, there is a rather large hole at the top of memory.  
: >> Currently, we do separate allocations around this whole.    You can't 
: >> get away from doing multiple cpu_register_physical_memory calls here.  
: >> We've discussed just allocating a single chunk with qemu_ram_alloc 
: >> since so many places in QEMU assume that you can do phys_ram_base + PA.
: >>
: >> I think I'll change this too into a single qemu_ram_alloc.  That will 
: >> fix the bug with KVM when using -kernel and large memory anyway :-)
: > 
: > Won't that cause all of the memory in the hole to be wasted?
: > 
: > You could munmap() it, but it's hardly elegant.
: > 
: 
: Linux doesn't commit mapped memory until it's faulted.  As for other 
: platforms, who knows?

Most BSDs are also similarly overcommitted. 95% of the users think
this is a feature, but the other 5 argue 20 times harder sometimes :-(

Warner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]