[PATCH] target/sparc: allow partial decode of v8 STBAR instructions

[PATCH] target/sparc: allow partial decode of v8 STBAR instructions

[Mark Cave-Ayland]

Solaris 8 appears to have a bug whereby it executes v9 MEMBAR instructions
when booting a freshly installed image. According to the SPARC v8
architecture manual, whilst bits 14 and bits 13-0 of the "Read State Register
Instructions" are notionally zero, they are marked as unused (i.e. ignored).
In effect the v9 MEMBAR instruction becomes a v8 STBAR instruction on a 32-bit
SPARC CPU.

Adjust the avail_32() logic in trans_MEMBAR() so that if a v9 MEMBAR
instruction is executed on 32-bit SPARC, the equivalent of a v8 STBAR
instruction is executed instead.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3097
---
 target/sparc/translate.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index b922e53bf1..9efefe41c6 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -2832,7 +2832,15 @@ static bool trans_STBAR(DisasContext *dc, arg_STBAR *a)
 static bool trans_MEMBAR(DisasContext *dc, arg_MEMBAR *a)
 {
     if (avail_32(dc)) {
-        return false;
+        /*
+         * At least Solaris 8 executes v9 MEMBAR instructions such as
+         * 0x8143e008 during boot. According to the SPARC v8 architecture
+         * manual, bits 13 and 12-0 are unused (notionally zero) so in
+         * this case if we assume the unused bits are not decoded then
+         * the instruction becomes 0x8143c000, or the equivalent of STBAR.
+         */
+        tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
+        return advance_pc(dc);
     }
     if (a->mmask) {
         /* Note TCG_MO_* was modeled on sparc64, so mmask matches. */
-- 
2.39.5

Re: [PATCH] target/sparc: allow partial decode of v8 STBAR instructions

[Richard Henderson]

On 9/4/25 18:10, Mark Cave-Ayland wrote:
> Solaris 8 appears to have a bug whereby it executes v9 MEMBAR instructions
> when booting a freshly installed image. According to the SPARC v8
> architecture manual, whilst bits 14 and bits 13-0 of the "Read State Register
> Instructions" are notionally zero, they are marked as unused (i.e. ignored).
> In effect the v9 MEMBAR instruction becomes a v8 STBAR instruction on a 32-bit
> SPARC CPU.
> 
> Adjust the avail_32() logic in trans_MEMBAR() so that if a v9 MEMBAR
> instruction is executed on 32-bit SPARC, the equivalent of a v8 STBAR
> instruction is executed instead.
> 
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3097
> ---
>   target/sparc/translate.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/target/sparc/translate.c b/target/sparc/translate.c
> index b922e53bf1..9efefe41c6 100644
> --- a/target/sparc/translate.c
> +++ b/target/sparc/translate.c
> @@ -2832,7 +2832,15 @@ static bool trans_STBAR(DisasContext *dc, arg_STBAR *a)
>   static bool trans_MEMBAR(DisasContext *dc, arg_MEMBAR *a)
>   {
>       if (avail_32(dc)) {
> -        return false;
> +        /*
> +         * At least Solaris 8 executes v9 MEMBAR instructions such as
> +         * 0x8143e008 during boot. According to the SPARC v8 architecture
> +         * manual, bits 13 and 12-0 are unused (notionally zero) so in
> +         * this case if we assume the unused bits are not decoded then
> +         * the instruction becomes 0x8143c000, or the equivalent of STBAR.
> +         */
> +        tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
> +        return advance_pc(dc);
>       }

You could avoid replicating this and do

     return trans_STBAR(dc, NULL);

Anyway,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [PATCH] target/sparc: allow partial decode of v8 STBAR instructions

[Mark Cave-Ayland]

On 04/09/2025 17:44, Richard Henderson wrote:

> On 9/4/25 18:10, Mark Cave-Ayland wrote:
>> Solaris 8 appears to have a bug whereby it executes v9 MEMBAR instructions
>> when booting a freshly installed image. According to the SPARC v8
>> architecture manual, whilst bits 14 and bits 13-0 of the "Read State Register
>> Instructions" are notionally zero, they are marked as unused (i.e. ignored).
>> In effect the v9 MEMBAR instruction becomes a v8 STBAR instruction on a 32-bit
>> SPARC CPU.
>>
>> Adjust the avail_32() logic in trans_MEMBAR() so that if a v9 MEMBAR
>> instruction is executed on 32-bit SPARC, the equivalent of a v8 STBAR
>> instruction is executed instead.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>> Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree")
>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3097
>> ---
>>   target/sparc/translate.c | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/sparc/translate.c b/target/sparc/translate.c
>> index b922e53bf1..9efefe41c6 100644
>> --- a/target/sparc/translate.c
>> +++ b/target/sparc/translate.c
>> @@ -2832,7 +2832,15 @@ static bool trans_STBAR(DisasContext *dc, arg_STBAR *a)
>>   static bool trans_MEMBAR(DisasContext *dc, arg_MEMBAR *a)
>>   {
>>       if (avail_32(dc)) {
>> -        return false;
>> +        /*
>> +         * At least Solaris 8 executes v9 MEMBAR instructions such as
>> +         * 0x8143e008 during boot. According to the SPARC v8 architecture
>> +         * manual, bits 13 and 12-0 are unused (notionally zero) so in
>> +         * this case if we assume the unused bits are not decoded then
>> +         * the instruction becomes 0x8143c000, or the equivalent of STBAR.
>> +         */
>> +        tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
>> +        return advance_pc(dc);
>>       }
> 
> You could avoid replicating this and do
> 
>      return trans_STBAR(dc, NULL);
> 
> Anyway,
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> 
> r~

Agreed, I think your suggestion is semantically clearer. I'll send a v2 shortly.


ATB,

Mark.