qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/4] target/arm: Update MSR access to UAO


From: Richard Henderson
Subject: Re: [PATCH 2/4] target/arm: Update MSR access to UAO
Date: Sat, 1 Feb 2020 17:00:53 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 12/6/19 10:30 AM, Peter Maydell wrote:
>> +    if (cpu_isar_feature(aa64_uao, cpu)) {
>> +        static const ARMCPRegInfo uao_reginfo[] = {
>> +            { .name = "UAO", .state = ARM_CP_STATE_AA64,
>> +              .opc0 = 3, .opc1 = 0, .crn = 4, .crm = 2, .opc2 = 4,
>> +              .type = ARM_CP_NO_RAW, .access = PL1_RW,
>> +              .readfn = aa64_uao_read, .writefn = aa64_uao_write, },
>> +            REGINFO_SENTINEL
>> +        };
> 
> This could just be a file-scope global, right?
> Also, you can just use define_one_arm_cp_reg() rather
> than having a list with one entry. (cf zcr_el1_reginfo).

Done.

>> +    case 0x03: /* UAO */
>> +        if (!dc_isar_feature(aa64_uao, s) || s->current_el == 0) {
>> +            goto do_unallocated;
>> +        }
>> +        if (crm & 1) {
>> +            set_pstate_bits(PSTATE_UAO);
>> +        } else {
>> +            clear_pstate_bits(PSTATE_UAO);
>> +        }
>> +        t1 = tcg_const_i32(s->current_el);
>> +        gen_helper_rebuild_hflags_a64(cpu_env, t1);
>> +        tcg_temp_free_i32(t1);
>> +        break;
> 
> Do we also need to end the TB since we've messed with
> the hflags, or is some bit of code not in the patch
> context handling that?

This is done by default.  We would have to do something special to avoid ending
the TB here.

> Does the "on exception entry PSTATE.UAO is zeroed" behaviour
> fall out automatically for us?

Yes, aarch64_pstate_mode() returns a clean PSTATE.

> How about "on exception entry
> from aarch32 to aarch64 SPSR_ELx.UAO is set to zero" ?

This follows the same path as above, as far as I can see.

> I think we may also want a minor code change so that an exception
> return from aarch64 to aarch32 doesn't copy a bogus SPSR UAO==1
> into the pstate/cpsr.

Well, there is no CPSR UAO bit, so there's no aarch32 bit to clear.  But I did
add a clearing of PSTATE UAO on the exception return to aarch64 path, to
prevent the guest from playing games with SPSR.


r~



reply via email to

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