From: Piotras <piotras@gmail.com>
To: Fabrice Bellard <fabrice@bellard.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] softmmu thoughts
Date: Fri, 17 Dec 2004 10:45:28 +0100 [thread overview]
Message-ID: <da63183704121701454b137bd1@mail.gmail.com> (raw)
In-Reply-To: <41C20947.8060808@bellard.org>
Hi!
On Thu, 16 Dec 2004 23:16:39 +0100, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> Here are a few points to look at:
>
> 1) MMU_MAP -> SOFT_MMU transition : more work is needed there, but I
> will look at it too, but not in the near future (I think the best
> solution is to recompile the TB directly in the fault handler - the goal
> is to suppress 'HF_SOFTMMU_MASK' which slows down the emulator).
This sounds reasonable.
> 2) Try to make a Windows port. It seems doable because when you create a
> 64 KB mapping in Windows you can select which 4 KB subpages are mapped.
At present I don't have Windows development environment -- I don't
even have Windows at home). Maybe someone could volunteer here?
> 3) Test it with the ppc emulation if not already done.
This will be my priority. It would be also nice to try PPC host.
> 4) Use assembly code in most of the SOFTMMU code to accelerate unaligned
> and I/O accesses (the current code is not optimized).
This is nice future project, but not relevant for this patch.
> 5) For you and me: reduce the number of ifdefs for SOFTMMU/MMU_MAP and
> mmap().
Agreed.
> 6) You can go even faster (at least on Linux or *BSD) by using hard mmu
> for pages between 0 and a given address 'L' by using mmap() and by using
> segment limits. You can fall back to MMU_MAP if the address is >= 'L',
> and fall back to soft MMU if I/O accesses are done. The advantage is
> that the 'code copy' mode can be used in that case, so you get closer to
> 1:1 performance on most of the user code.
Also it would be nice to investigate possibility to setting up two LDT
entries -- one for accessing 0-"L" memory range and another for
accessing "L1"-0xffffff range (using expansion direction flag of segment
descriptor). Probably it could be possible to mix two in single TB (one
for data and other for stack access).
However at present I'm more interested in non-code-copy case.
> Fabrice.
Regards,
Piotrek
next prev parent reply other threads:[~2004-12-17 10:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1098217677.26133.26.camel@kubu.opensource.se>
[not found] ` <da63183704101917137df1cdc6@mail.gmail.com>
[not found] ` <da631837041019172720317e1c@mail.gmail.com>
[not found] ` <4175B3CA.9050209@sti.net>
[not found] ` <da63183704102000527be2cc6a@mail.gmail.com>
[not found] ` <41765D06.4020006@bellard.org>
2004-12-14 17:54 ` [Qemu-devel] softmmu thoughts Piotras
2004-12-15 7:50 ` Jens Arm
2004-12-15 7:59 ` Jens Arm
2004-12-16 12:22 ` Piotras
2004-12-16 15:53 ` Elefterios Stamatogiannakis
2004-12-16 16:49 ` Jens Arm
2004-12-16 17:21 ` André Braga
2004-12-16 21:28 ` Piotras
2004-12-16 21:43 ` Jim C. Brown
2004-12-16 22:16 ` Fabrice Bellard
2004-12-17 9:45 ` Piotras [this message]
2004-12-18 18:59 ` Magnus Damm
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=da63183704121701454b137bd1@mail.gmail.com \
--to=piotras@gmail.com \
--cc=fabrice@bellard.org \
--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).