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

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

Paul Brook wrote:
>>> I agree with the fact that ram_size should be 64 bit. Maybe each
>>> machine could test the value and emit an error message if it is too
>>> big. Maybe an uint64_t would be better though.
>>>       
>> uint64_t is probably more reasonable.  I wouldn't begin to know what the
>> appropriate amount of ram was for each machine though so I'll let the
>> appropriate people handle that :-)
>>     
>
> I'd say ram_addr_t is an appropriate type.
> Currently this is defined in cpu-defs.h. It should probably be moved elsewhere 
> because in the current implementation it's really a host type.
>   

Okay, it turns out that patch needed a lot of refactoring.  I agree that 
changing ram_addr_t to a host type is the right thing to do.

> If we ever implement >2G ram on a 32-bit host this may need some rethinking.  
> We can deal with that if/when it happens though.  Requiring a 64-bit host for 
> large quantities of ram seems an acceptable limitation (N.B. I'm only talking 
> about ram size, not target physical address size).
>   

My current limitation is < 2GB if HOST_BITS==32 or defined(USE_KQEMU).  
USE_KQEMU restricts the size of the phys_map which limits the maximum 
physical address size.  I guess technically USE_KQEMU could allow up to 
around 3GB of ram but I preferred to simplify the logic.

Regards,

Anthony Liguori

> Paul
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>