qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Cc: blauwirbel@gmail.com, izike@qumranet.com
Subject: Re: [Qemu-devel] Updated >2G memory patch
Date: Sat, 29 Sep 2007 15:34:42 +0200	[thread overview]
Message-ID: <1191072882.29900.39.camel@rapid> (raw)
In-Reply-To: <f43fc5580709290604i45a7bb8bwe7c21c7d4ea89af@mail.gmail.com>

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 been ported to those systems.
> 
> Therefore I don't have much interest to continue to this direction. Is
> the patch OK for other targets? I'd like to commit this soon.

Imho, having 42 bits of physical address space as a default is clearly
not a good solution.
First of all, it's a nonsense for most 32 bits machines emulation.
Then, it makes the l1_map and l1_phys_map tables grow from 1024 entries
to 1048576 entries which is quite awful. And this model cannot be
extended to emulate a full 64 bits address space: this would make the
tables so huge that the emulator would even not be able to run on most
host machines.
The 42 bits L1_SIZE extension I did for alpha emulation was a quick
hack, as the associated comment says. It clearly cannot be generalized
and a more cleaver model should be used, with multi level tables, _only_
if the emulated target really needs more than 32 bits of physical
address space, this not to have any performance impact on the 32 bits
only targets emulation.

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.

Regards.

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

  parent reply	other threads:[~2007-09-29 13:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29 13:04 [Qemu-devel] Updated >2G memory patch Blue Swirl
2007-09-29 13:33 ` [Qemu-devel] " Izik Eidus
2007-09-29 13:40   ` Izik Eidus
2007-09-29 13:34 ` J. Mayer [this message]
2007-09-29 15:54   ` [Qemu-devel] " Blue Swirl
2007-09-29 22:43     ` Paul Brook
2007-09-29 23:16       ` J. Mayer
2007-09-30  0:02         ` Paul Brook
2007-09-30  0:34           ` J. Mayer
2007-09-30 15:43             ` Paul Brook
2007-09-30  7:15         ` Blue Swirl
2007-09-30 12:31           ` J. Mayer
2007-09-30 14:37             ` Avi Kivity
2007-09-30 15:30             ` Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1191072882.29900.39.camel@rapid \
    --to=l_indien@magic.fr \
    --cc=blauwirbel@gmail.com \
    --cc=izike@qumranet.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).