qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).