Re: [PATCH 4/9] target/microblaze: Use uint64_t for CPUMBState.ear

[Richard Henderson <richard.henderson@linaro.org>]

On 2/13/25 04:42, Philippe Mathieu-Daudé wrote:
> On 12/2/25 23:01, Richard Henderson wrote:
>> Use an explicit 64-bit type for EAR.
>>
>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>> ---
>>   target/microblaze/cpu.h       | 2 +-
>>   target/microblaze/translate.c | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/target/microblaze/cpu.h b/target/microblaze/cpu.h
>> index 45f7f49809..01571d4f86 100644
>> --- a/target/microblaze/cpu.h
>> +++ b/target/microblaze/cpu.h
>> @@ -248,7 +248,7 @@ struct CPUArchState {
>>       uint32_t pc;
>>       uint32_t msr;    /* All bits of MSR except MSR[C] and MSR[CC] */
>>       uint32_t msr_c;  /* MSR[C], in low bit; other bits must be 0 */
>> -    target_ulong ear;
>> +    uint64_t ear;
>>       uint32_t esr;
>>       uint32_t fsr;
>>       uint32_t btr;
>> diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c
>> index d5c5e650e0..549013d25e 100644
>> --- a/target/microblaze/translate.c
>> +++ b/target/microblaze/translate.c
>> @@ -1842,7 +1842,7 @@ void mb_cpu_dump_state(CPUState *cs, FILE *f, int flags)
>>       }
>>       qemu_fprintf(f, "\nesr=0x%04x fsr=0x%02x btr=0x%08x edr=0x%x\n"
>> -                 "ear=0x" TARGET_FMT_lx " slr=0x%x shr=0x%x\n",
>> +                 "ear=0x%" PRIx64 " slr=0x%x shr=0x%x\n",
>>                    env->esr, env->fsr, env->btr, env->edr,
>>                    env->ear, env->slr, env->shr);
> 
> So IIUC no need to worry about the upper 32-bits as Anton
> suggested in my RFC:
> https://lore.kernel.org/qemu-devel/ 
> rbczkcp7whvovj55htcvongsc45xyhia5sgckqunszldag3iey@4vsbsjak4wr2/

The upper 32 bits can only be written by the 64-bit "extended address" instructions, which 
are supervisor only.  So certainly the upper 32-bits are not relevant to linux-user.

We are not currently, but *should* be writing to ear from linux-user so that ear gets 
populated in the signal context.  We're missing a record_sigsegv hook.


r~