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

[Paul Brook]

> > IMHO Huge amounts of virtual address space can definitely be useful, even
> > if you don't have ram to back it.
> >
> > Huge amounts of physical address space is less immediately useful, though
> > in practice you have to emulate whatever real hardware provides. If
> > you're emulating a machine with a 40+ bit physical address space, there's
> > a fair chance your guest OS will decide to scatter a relatively small set
> > of resources over the whole address space.
>
> I don't agree too much with your opinion, because what I can see is that
> PowerPC 64 machines (at least IBM ones) tend to use the 62 bits physical
> address space provided by the architecture. If I remember well, there is
> at least one PPC64 architecture where the highest bits are used to split
> the physical address space between memory, memory-mapped IO,
> devices, ...
> I'm quite sure there are other 64 bits architecture that have the same
> requirement of a huge physical address space, then beeing able to handle
> it in Qemu seems to be very useful, much more than trying to emulate a
> huge amount of RAM, and is needed in a very near future.

I'm confused. You say you don't agree with me, then give an example that 
confirms what I said (Replace Guest OS with machine memory map as 
appropriate).

> > I agree there's no point trying to emulate >2G ram on a 32-bit host, but
> > physical address space and ram are two very different things.
> > For example I have a cpu that has a "bitbanded" memory region. This
> > expands each bit of real ram to a whole 32-bit word, effectively turning
> > a word load/store into an atomic bit operation. Currently it's only used
> > for relatively small address ranges, but it's a good example of a
> > situation where the physical address space is much larger than ram.
>
> I don't see why it would be useless to emulate huge amount of RAM on 32
> bits hosts. If you try to register more than a few gigabytes of memory,
> there are great chances that the host machine won't have the physical
> RAM to handle it at once, so a page swap mechanism will have to be
> implemented. Then, I see no difference in using it on a 32 bits hosts or
> a 64 bits ones.

The difference is that on a 32-bit host you have to manually page guest ram to 
make if fit in the host address space. On a 64-bit host you can just do a big 
malloc any let the host OS deal with it. Implementing a swap-to-disk memory 
manager inside qemu really doesn't seem like a good use of resources given 
pretty much all new host hardware is 64-bit and the host OS has already 
solved the problem for us.

Some form of dynamic ram allocation is a reasonable feature. Demand paging is 
a much bigger and harder problem.

Emulating a machine with more ram than the host is IMHO not something a normal 
end user should be doing. Performance is going to be abysmal however it's 
implemented, and probably only useful for smoketesting low level OS support. 
It seems entirely reasonable to limit this to 64-bit hosts.

I have absolutely no sympathy for people who are running 32-bit OS on machines 
with >2G ram. Pretty much any machine with that much ram is also capable of 
running a 64-bit host OS.

Paul