Re: [PATCH 14/14] target/arm: enable Secure EL2 in max CPU

[Rémi Denis-Courmont]

Le maanantaina 2. marraskuuta 2020, 12.58.02 EET 
remi.denis.courmont@huawei.com a écrit :
> From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> 
> Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> ---
>  target/arm/cpu64.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 649213082f..8c3749268e 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -641,6 +641,7 @@ static void aarch64_max_initfn(Object *obj)
>          t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
>          t = FIELD_DP64(t, ID_AA64PFR0, FP, 1);
>          t = FIELD_DP64(t, ID_AA64PFR0, ADVSIMD, 1);
> +        t = FIELD_DP64(t, ID_AA64PFR0, SEL2, 1);
>          cpu->isar.id_aa64pfr0 = t;
> 
>          t = cpu->isar.id_aa64pfr1;

Answering my own patch as I have a policy question here...

This exposes SEL2 without TTST (small translation tables). On a logical level, 
the two extensions are orthogonal. But per DDI0487, SEL2 implies TTST, so I am 
not sure if this is considered an acceptable deviation in QEMU, or if 
implementing TTST is deemed necessary.

Note that there's what seems like an editorial error in the spec: VSTCR 
documentation covers the scenario that TTST is not supported by the CPU, even 
though then VSTCR should not exist.

-- 
Реми Дёни-Курмон
http://www.remlab.net/