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~