> > 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
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 been ported to those systems.
Therefore I don't have much inter
12 matches
Mail list logo
