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

[J. Mayer]

On Sun, 2007-09-30 at 01:02 +0100, Paul Brook wrote:
> > > 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).

What I don't agree is the fact that emulating huge amount of physical
address space is not immediatly useful.
My example was here to say that even if some hardware implementation use
a relativally small amount of the physical address space provided by the
architecture (Imac G5, for example, maps all its devices in a 32 bits
physical address space), some others use the full range available, to
explain why I think we have to think about a solution to this problem
very soon.

Sorry for bringing confusion...

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

Then, it's a geek only feature, until most people have 64 bits machines,
with 64 bits OSes and user mode environment, at home to be able to use
it, which will take years (most people don't buy a new PC every year,
even most companies don't....).
I think that it could be more efficient to handle the page swapping in
the emulator rather than let the OS do it, I may be wrong on that point.
I agree that it would greatly slowdown the emulation. But one of the
goals of Qemu, at least for me, is also to provide a way to develop and
evaluate an architecture and test some software without the need of
having the hardware platform available. If one uses Qemu in that way, I
guess he would prefer to be able to have all features available and
won't care too much about performances. For this kind of usage, you want
to be able to fully emulate any guest machine on any host, whatever the
cost.
But I agree that for the one who wants to do virtualization with Qemu,
performance is the main point, then page swapping cannot be accepted.
Then, I don't think Qemu is the good way to achieve this, when platforms
with hardware virtualization support have been available for years and
are now the main-stream for server CPUs...

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

You sure are right. But the point, imho, is: how to emulate all
available targets with all features, including 64 bits ones, on the mean
end-user PC ? This PC, as far as I know, is not a 64 bits machine. Most
end user will run in a full 64 bits environment in a few years, but they
don't now. And what we need is a way to provide features for what the
environment they use today....

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