Re: [PATCH v5 04/22] target/arm: Add helper_mte_check{1,2,3}

[Richard Henderson]

On 12/3/19 1:42 PM, Peter Maydell wrote:
>> +static int allocation_tag_from_addr(uint64_t ptr)
>> +{
>> +    ptr += 1ULL << 55;  /* carry ptr[55] into ptr[59:56].  */
>> +    return extract64(ptr, 56, 4);
> 
> What's the carry-bit-55 logic for? The pseudocode
> AArch64.AllocationTagFromAddress just returns bits [59:56].

This was the old physical tag extraction.

>> +static uint64_t do_mte_check(CPUARMState *env, uint64_t dirty_ptr,
>> +                             uint64_t clean_ptr, uint32_t select,
>> +                             uintptr_t ra)
>> +{
>> +    ARMMMUIdx stage1 = arm_stage1_mmu_idx(env);
>> +    int ptr_tag, mem_tag;
>> +
>> +    /*
>> +     * If TCMA is enabled, then physical tag 0 is unchecked.
>> +     * Note the rules in D6.8.1 are written with logical tags, where
>> +     * the corresponding physical tag rule is simpler: equal to 0.
>> +     * We will need the physical tag below anyway.
>> +     */
> 
> This reads a bit oddly, because (in the final version of the spec)
> physical and logical tags are identical (AArch64.PhysicalTag()
> just returns bits [59:56] of the vaddr).

I missed that change between draft and final.

Wow, that's really annoying.  If they were going to drop physical vs logical
tags, why did they keep the language?

Frankly, it made a *lot* of sense as a way to handle addresses in TTBR1, which
now have asymmetric special cases.  In particular, ADDG will, as I read it now,
with allocation tag access disabled, munge a TTBR1 address to <59:56> = 0.
Which is fine so long as access is disabled, but when re-enabled (e.g. via
PSTATE.TCO) the address will no longer pass the TCMA test.

Is this really intentional?


r~