qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Updated >2G memory patch


From: J. Mayer
Subject: Re: [Qemu-devel] Updated >2G memory patch
Date: Sat, 29 Sep 2007 15:34:42 +0200

On Sat, 2007-09-29 at 16:04 +0300, Blue Swirl wrote:
> I updated the >2G memory patch a bit. It seems that Linux and the BSDs
> do not support having more than 4G of memory on Sparc32. There may
> have been real machines with up to 5G of memory and even 16G on Crays,
> but probably Linux hasn't been ported to those systems.
> 
> Therefore I don't have much interest to continue to this direction. Is
> the patch OK for other targets? I'd like to commit this soon.

Imho, having 42 bits of physical address space as a default is clearly
not a good solution.
First of all, it's a nonsense for most 32 bits machines emulation.
Then, it makes the l1_map and l1_phys_map tables grow from 1024 entries
to 1048576 entries which is quite awful. And this model cannot be
extended to emulate a full 64 bits address space: this would make the
tables so huge that the emulator would even not be able to run on most
host machines.
The 42 bits L1_SIZE extension I did for alpha emulation was a quick
hack, as the associated comment says. It clearly cannot be generalized
and a more cleaver model should be used, with multi level tables, _only_
if the emulated target really needs more than 32 bits of physical
address space, this not to have any performance impact on the 32 bits
only targets emulation.

Also note that changing variables from int to long have strictly no
impact on 32 bits host machines, then won't help emulating more than 2
GB of RAM. Another variable type (target_phys_addr_t ?) should be used
instead.

Regards.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

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