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

["J. Mayer" <l_indien@magic.fr>]

On Sun, 2007-09-30 at 10:15 +0300, Blue Swirl wrote:
> On 9/30/07, J. Mayer <l_indien@magic.fr> wrote:
> > On Sat, 2007-09-29 at 23:43 +0100, Paul Brook wrote:
> > > > > 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 feeling is that if it's restricted to 64 bits host, then it's a patch
> > for geeks only, that brings no useful feature to the main end-users. In
> > the real world, most people are still running in 32 bits mode.
> 
> I think Qemu is a geek application. The majority of people with their
> i386 Windows PCs don't know or care about, for example Sparc32
> targets, or even about Qemu. The people who know about Qemu are
> probably geeks, they already have some kind of need to emulate
> hardware. I'd think majority of them still want to emulate an i386
> target on their i386/x86_64 host. Other targets and hosts are a
> minority, making the people interested in those even geekier.
> 
> But whether this patch or something else is a geek feature or not is
> irrelevant. What matters is whether it breaks something or not, or if
> some part of the design is objectionable. I fully agree with you that
> some parts could be designed differently.

About the design, my opinion is:
- to support wider physical address spaces:
* full 32 bits targets (ie 32 bits virtual & physical address spaces)
should stay 32 bits.
* for 32 bits targets with a few more bits for their physical address
space (like the ppcemb target, which has 36 bits of physical address
space and I guess x86 with PAE extension), it seems acceptable to only
adjust the L1_BITS constants.
* for 64 bits targets, a multiple level table has to be used to avoid
the need of huge l1_xxx tables. This includes the alpha target (42 bits
of physical address space), for which I recognize the quick hack I did
commit is not really acceptable.
- to support more than 2 GB of RAM:
I still think you should have to use a consistent type here, not just
unsigned long.
Do you really need another new type ? It seems to me that  one of
physical_addr_t or ram_addr_t could be used ?

-- 
J. Mayer <l_indien@magic.fr>
Never organized