Re: [Qemu-devel] [PATCH 09/20] target/arm: Handle SVE vector length changes in system mode

[Richard Henderson]

On 08/17/2018 09:22 AM, Peter Maydell wrote:
>> +    /*
>> +     * When FP is enabled, but SVE is disabled, the effective len is 0.
>> +     * ??? How should sve_exception_el interact with AArch32 state?
>> +     * That isn't included in the CheckSVEEnabled pseudocode, so is the
>> +     * host kernel required to explicitly disable SVE for an EL using aa32?
>> +     */
> I'm not clear what you're asking here. If the EL is AArch32
> then why does it make a difference if SVE is enabled or disabled?
> You can't get at it...
> 
>> +    old_len = (sve_exception_el(env, old_el)
>> +               ? 0 : sve_zcr_len_for_el(env, old_el));
>> +    new_len = (sve_exception_el(env, new_el)
>> +               ? 0 : sve_zcr_len_for_el(env, new_el));

Yes the registers are inaccessible.  But...

It may be that we must produce old_len/new_len == 0 if old_el/new_el is in
32-bit mode, so that the high part of the SVE registers are zeroed.

However, it may be UNDEFINED what happens if the OS switches to an el in 32-bit
mode while CPACR.ZEN == 3.  And if so, then there may be no point in adding an
additional test here.

So far I have re-worded the comment as:

     * ??? Do we need a conditional for old_el/new_el in aa32 state?
     * That isn't included in the CheckSVEEnabled pseudocode, so is the
     * host kernel required to explicitly disable SVE for an EL using aa32?

Thoughts on the underlying issue?


r~