[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 03/22] target/arm: Add MTE system registers
|
From: |
Richard Henderson |
|
Subject: |
Re: [PATCH v5 03/22] target/arm: Add MTE system registers |
|
Date: |
Fri, 6 Dec 2019 06:47:05 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 |
On 12/3/19 3:48 AM, Peter Maydell wrote:
>> + { .name = "GMID_EL1", .state = ARM_CP_STATE_AA64,
>> + .opc0 = 3, .opc1 = 1, .crn = 0, .crm = 0, .opc2 = 4,
>> + .access = PL1_R, .type = ARM_CP_CONST, .resetvalue = GMID_EL1_BS },
>
> This should trap if HCR_EL2.TID5 is 1 (since we're adding
> support for the TID* ID reg trap bits now).
Done.
> So, aa64_mte_insn_reg here is checking for ID_AA64PFR1_EL1 != 0
> ("instructions accessible at EL0 are implemented")
> and aa64_mte is checking for >= 2 ("full implementation").
> I think a couple of brief comments would clarify:
Done.
> (The other way to arrange this would be to have the 'real'
> TCO regdef in mte_reginfo, and separately have "reginfo
> if we only have the dummy visible-from-EL0-parts-only
> which defines a constant 0 TCO" (and also make the MSR_i
> code implement a RAZ/WI for this case, for consistency).
Done. I agree this is a better way to treat the EL0-only case...
> An implementation that allows the guest to toggle the PSTATE.TCO
> bit to no visible effect is architecturally valid, though.
... because this could turn out to be slightly confusing.
r~