From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user
Date: Fri, 26 Jun 2009 20:24:30 +0100 [thread overview]
Message-ID: <200906262024.31543.paul@codesourcery.com> (raw)
In-Reply-To: <20090626190714.GA464@miranda.arrow>
> Stupid idea, I expect, but would it be possible to handle EXECUTE by
> 'branching' to the 'instruction stored somewhere in memory', using one
> bit to hold the state of R0, and another indicate that the TB is a
> special EXECUTE TB (i.e. only a single instruction should be decoded,
> the LSB of R0 should be ORed, and code must be generated to return to
> the 'caller'), and another bit for the state of the LSB of R0?
I guess s/bit/byte/.
> Presumably, SMC handling would safely deal with the memory holding that
> instruction being written to. (If all variants of S/390 need precise
> SMC handling, I suppose that shouldn't be a problem?)
You don't need precise SMC here. That's only required if a TB can modify
itself.
> My only real concern would be that it must not be possible to observe
> this behaviour. (I.e. an interrupt arriving at the 'wrong' moment or
> the EXECUTEd instruction faulting must be properly handled.)
That's easy to fix. We already do this for other targets (e.g. ARMv7-M
exception return). You already need an extra TB flag bit to indicate that this
is part way through an EXECUTE instruction.
> Also, if S/390 has separate read/execute page bits, would access to the
> memory location in question still count as 'execution'? I suppose this
> would also be possible to work around, though...
This is probably the trickiest bit to get right, especially if the you end up
causing a fault.
Paul
next prev parent reply other threads:[~2009-06-26 19:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 16:49 [Qemu-devel] [RFC PATCH] s390x-linux-user Ulrich Hecht
2009-06-26 17:17 ` Blue Swirl
2009-06-26 17:40 ` Paul Brook
2009-06-26 17:46 ` Blue Swirl
2009-06-26 17:59 ` Paul Brook
2009-06-26 18:18 ` Paul Brook
2009-06-26 18:22 ` Blue Swirl
2009-06-26 18:39 ` Paul Brook
2009-06-26 19:07 ` Stuart Brady
2009-06-26 19:24 ` Paul Brook [this message]
2009-07-03 15:11 ` Ulrich Hecht
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=200906262024.31543.paul@codesourcery.com \
--to=paul@codesourcery.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).