> > 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.
Ah, ok. I meant i
On 9/30/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> 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
> s
J. Mayer wrote:
* 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.
We can allocate a sparse table
On Sun, 2007-09-30 at 10:15 +0300, Blue Swirl wrote:
> On 9/30/07, J. Mayer <[EMAIL PROTECTED]> 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 em
On 9/30/07, J. Mayer <[EMAIL PROTECTED]> 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
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 wh
> > 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 machin
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.
> >
> > 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 th
On 9/29/07, J. Mayer <[EMAIL PROTECTED]> 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
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 bee
11 matches
Mail list logo
