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

["Blue Swirl" <blauwirbel@gmail.com>]

On 9/29/07, J. Mayer <l_indien@magic.fr> wrote:
> Imho, having 42 bits of physical address space as a default is clearly
> not a good solution.

I agree that the number of bits could be reduced. Something like 36
bits (64G) should be enough for some years.

> First of all, it's a nonsense for most 32 bits machines emulation.

Well, it's useful for i386 (PAE etc.), which is probably the most
common target and other targets could use the 2G to 4G range for a
small benefit.

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

You're right, this part would need some rework.

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

This patch should be restricted to 64-bit hosts. I don't think it's
useful to emulate a 64-bit target with huge amounts of virtual and
physical address space on a 32-bit host.

My first patch changed a lot of unsigned longs to new host_phys_addr_t
type. But I think it is too intrusive at this stage, so I changed just
the ints and uint32_ts to unsigned long where applicable. Also the
correct name would be host_virt_addr_t, user space don't use physical
addresses.