All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Richard Henderson" <richard.henderson@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org
Cc: qemu-s390x@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
	Thomas Huth <thuth@redhat.com>
Subject: Re: [PATCH v2] s390x/tcg: MVCL: Exit to main loop if requested
Date: Fri, 4 Oct 2019 10:00:24 +0200	[thread overview]
Message-ID: <17a008ed-8ec0-2732-347d-bb04b6d832e8@redhat.com> (raw)
In-Reply-To: <379c2065-adfe-0847-46f3-7f25c7650df9@linaro.org>

On 02.10.19 21:34, Richard Henderson wrote:
> On 10/2/19 9:47 AM, Richard Henderson wrote:
>> There is still the special case of EXECUTE of MVCL, which I suspect must have
>> some failure mode that we're not considering -- the setting and clearing of
>> ex_value can't help.  I have a suspicion that we need to special case that
>> within helper_ex, just so that ex_value doesn't enter into it.
> 
> I had a walk and a think.  I now believe that we're ok:
> 
> (1) TB with EXECUTE runs, at address Ae
> 
>     - env->psw_addr stored with Ae.
>     - helper_ex() runs, memory address Am computed
>       from D2a(X2a,B2a) or from psw.addr+RI2.
>     - env->ex_value stored with memory value modified by R1a
> 
> (2) TB of executee runs,
> 
>     - env->ex_value stored with 0.
>     - helper_mvcl() runs, using and updating R1b, R1b+1, R2b, R2b+1.
> 
> (3a) helper_mvcl() completes,
> 
>      - TB of executee continues, psw.addr += ilen.
>      - Next instruction is the one following EXECUTE.

Right, and whenever we inject an interrupt (e.g., access exception or an
asynchronous one), we have to use addr=ilen of EXECUTE, not of the
execute target. And that is guaranteed to reside in env->psw_addr/rewind
info

> 
> (3b) helper_mvcl() exits to main loop,
> 
>      - cpu_loop_exit_restore() unwinds psw.addr = Ae.
>      - Next instruction is the EXECUTE itself...
>      - goto 1.

Sounds about right to me. Thanks for verifying.

> 
> If we can agree that the result is undefined if registers R1a, X2a, B2a overlap
> R1b, R1b+1, R2b, R2b+1, or if the memory address Am is modified by the
> interrupted MVCL, then we're ok.

So the Programming Note 5. for EXECUTE says:

When an interruptible instruction is made the tar-
get of an execute-type instruction, the program
normally should not designate any register
updated by the interruptible instruction as the R1,
X2, or B2 register for EXECUTE or R1 register for
EXECUTE RELATIVE LONG. Otherwise, on
resumption of execution after an interruption, or if
the instruction is refetched without an interrup-
tion, the updated values of these registers will be
used in the execution of the execute-type instruc-
tion. Similarly, the program should normally not
let the destination field in storage of an interrupt-
ible instruction include the location of an execute-
type instruction, since the new contents of the
location may be interpreted when resuming exe-
cution.

So, if I read correctly
- The updated register content *will* be used
- The updated memory content *may* be used

However, also "the program normally should not"/"the program should
normally not" which to me sounds like "just don't do it", in which case
we are fine.

So shall we leave this patch as-is (adding a summary of what you
explained to the description) or shall we somehow factor out the
TCG-internal-thingy check?

-- 

Thanks,

David / dhildenb


  reply	other threads:[~2019-10-04  8:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02  8:26 [PATCH v2] s390x/tcg: MVCL: Exit to main loop if requested David Hildenbrand
2019-10-02  9:58 ` Alex Bennée
2019-10-02 16:47   ` Richard Henderson
2019-10-02 18:19     ` David Hildenbrand
2019-10-02 19:34     ` Richard Henderson
2019-10-04  8:00       ` David Hildenbrand [this message]
2019-10-04 11:37         ` Alex Bennée
2019-10-04 12:11         ` Peter Maydell
2019-10-04 12:34           ` David Hildenbrand
2019-10-04 13:15             ` Alex Bennée
2019-10-04 15:34             ` 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=17a008ed-8ec0-2732-347d-bb04b6d832e8@redhat.com \
    --to=david@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.