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 > ------------------------------------------------------------------------- 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
