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

[Anthony Liguori <aliguori@us.ibm.com>]

Paul Brook wrote:
> On Thursday 31 January 2008, Anthony Liguori wrote:
>   
>> KVM supports more than 2GB of memory for x86_64 hosts.  The following patch
>> fixes a number of type related issues where int's were being used when they
>> shouldn't have been.  It also introduces CMOS support so the BIOS can build
>> the appropriate e820 tables.
>>     
>
> You've still got a fairly random mix of unsigned long, ram_addr_t and 
> uint64_t.
>   

I wasn't the one that did this work, but we've tested KVM with very 
large amounts of memory (~15GB I believe).  I suspect the changes were 
driven by trial and error.  Perhaps Izik can shed more light on how 
things were changed?

>> -typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
>> +typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,
>>     
>
> This breaks every target except x86.
>
>   

Indeed.  I missed this because it's only a warning since it's just a 
pointer cast.  I'll fix the patch for all the remaining targets.  Thanks!

>> +    if (above_4g_mem_size) {
>> +        rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size >> 16);
>> +        rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24);
>> +        rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32);
>>     
>
> This will cause warnings on 32-bit hosts.
>   

Yeah, it needs a (uint64_t), I'll update.

>> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
>>     
>
> This seems fairly arbitrary. Why? Any limit is certainly target specific.
>   

On a 32-bit host, a 2GB limit is pretty reasonable since you're limited 
in virtual address space.  On a 64-bit host, there isn't this 
fundamental limit.  If a target may have it's own limit but there is 
definitely a host imposed limit.

2047GBs is a somewhat arbitrary limit though for 64-bit hosts.  If you 
have a more logical suggestion, I'll happily change it.

Regards,

Anthony Liguori


> Paul
>