[Top][All Lists]

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

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

From: Anthony Liguori
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support
Date: Fri, 01 Feb 2008 11:49:10 -0600
User-agent: Thunderbird (X11/20071229)

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.


Anthony Liguori


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
kvm-devel mailing list

reply via email to

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