Re: [Qemu-devel] [PATCH v2 06/27] target/sh4: Handle user-space atomics

From: Richard Henderson <rth@twiddle.net>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org, laurent@vivier.eu, bruno@clisp.org,
	glaubitz@debian.org
Subject: Re: [Qemu-devel] [PATCH v2 06/27] target/sh4: Handle user-space atomics
Date: Sun, 16 Jul 2017 09:35:05 -1000	[thread overview]
Message-ID: <e19112df-a491-2e34-61a7-3a514622df3e@twiddle.net> (raw)
In-Reply-To: <20170716151802.cmaz3zhucqlgaq5r@aurel32.net>

On 07/16/2017 05:18 AM, Aurelien Jarno wrote:
> That said for further improvements did you consider decoding the gUSA
> section in a helper. It might avoid having to emulate the atomic
> sequence with 3 TBs in the worst case (the original one, the one to
> decode the sequence and the one holding the exclusive lock). The helper
> should directly have access to the r0 value, can decode the atomic
> sequence and translate it into a call to the corresponding atomic
> helpers. In the best case that means the sequence can be done in the
> same TB. In the worst case, where the gUSA sequence is not recognized
> it means two TB.

I did not consider decoding the sequence in a helper.

I do want to cache the result in a TB, so that when we execute the atomic 
sequence for a second time we do not have to re-interpret it.  And I don't see 
how to do that with a helper.

I *could* remember a mova into R0 earlier within the same block that performs 
the mov #imm,r15.  It's not guaranteed to be in the same TB, but looking 
through dumps from debian unstable it's highly likely.

That could end up with the atomic sequence in the same TB that set SP, or with 
the EXCP_ATOMIC exception in the same TB.

If it's ok with you, I'd prefer to handle that as a follow up.  We would still 
have to have the current setup as a backup just in case the mova isn't visible.

r~