qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH v2 06/27] target/sh4: Handle user-space atomics
Date: Sun, 16 Jul 2017 09:35:05 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]