From: "Alex Bennée" <alex.bennee@linaro.org>
To: David Hildenbrand <david@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
qemu-s390x@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2] s390x/tcg: MVCL: Exit to main loop if requested
Date: Fri, 04 Oct 2019 12:37:59 +0100 [thread overview]
Message-ID: <87h84oivvs.fsf@linaro.org> (raw)
In-Reply-To: <17a008ed-8ec0-2732-347d-bb04b6d832e8@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> 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?
It would be nice to avoid this internal detail in the guest specific
code but I can live with it for now.
Acked-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
next prev parent reply other threads:[~2019-10-04 12:04 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
2019-10-04 11:37 ` Alex Bennée [this message]
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=87h84oivvs.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cohuck@redhat.com \
--cc=david@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.