From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Richard Henderson <rth@twiddle.net>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Anton Blanchard <anton@au1.ibm.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] ppc: Stop dumping state on all exceptions in linux-user
Date: Sun, 07 Aug 2016 10:50:16 +1000 [thread overview]
Message-ID: <1470531016.12584.180.camel@kernel.crashing.org> (raw)
In-Reply-To: <ebfac624-5f94-b79a-21f1-3cad99996dcb@twiddle.net>
On Sat, 2016-08-06 at 15:23 +0530, Richard Henderson wrote:
> On 08/03/2016 05:09 PM, Benjamin Herrenschmidt wrote:
> >
> > As far user-with-softmmu, I'm not too sure... softmmu significantly
> > increases the overhead of load and stores. Maybe after we add 128-bit
> > integers to TGC to alleviate that a bit ? :-)
>
> It wouldn't be mandatory, but there are certain bugs we can't fix without it.
> The big issues to be fixed with softmmu are
>
> (1) Host page size > guest page size.
>
> E.g. there are many programs (i386, sparc, etc, all with 4k pages) that you
> can't even load, much less run, on a ppc64 host using a 64k page size.
Can't we advertise the host page size to the guest ? Or there are too many
compiled-in assumptions ?
> > (2) Host virtual address space bits != guest virtual address space bits
>
> My alpha emulation has run into this. A real Alpha guest has a 44-bit address
> space, but an x86_64 host has a 48-bit address space. The x86_64 kernel cannot
> be persuaded to reliably map memory below (1ul << 44), so I have to pretend
> than Alpha has a 48-bit address space. (Indeed, I set this to 63 bits, so that
> it works for even wider va, like on ppc64 and sparc64.)
You can't just set a no-access VMA covering the top of the address space ? Are
alpha programs relying on the fact that they won't get addresses above 44 ?
> > More theoretically, if the guest uses high bits for some purpose (e.g. ia64
> segmentation in the top 3 bits), and the host doesn't have a full 64-bit
> virtual address space, then we cannot even map the program, since we cannot set
> bits 61-63 to non-zero values.
I see. We could definitely have the option then.
Cheers,
Ben.
next prev parent reply other threads:[~2016-08-07 0:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 8:02 [Qemu-devel] [PATCH] ppc: Stop dumping state on all exceptions in linux-user Benjamin Herrenschmidt
2016-08-03 11:05 ` Peter Maydell
2016-08-03 11:28 ` Benjamin Herrenschmidt
2016-08-03 11:32 ` Peter Maydell
2016-08-03 11:39 ` Benjamin Herrenschmidt
2016-08-06 9:53 ` Richard Henderson
2016-08-07 0:50 ` Benjamin Herrenschmidt [this message]
2016-08-08 6:59 ` Richard Henderson
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=1470531016.12584.180.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=anton@au1.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
/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).