[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
From: |
Richard Henderson |
Subject: |
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements |
Date: |
Tue, 26 Nov 2019 21:04:16 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 11/23/19 11:56 AM, Marc Zyngier wrote:
> HCR_EL2.TID3 mandates that access from EL1 to a long list of id
> registers traps to EL2, and QEMU has so far ignored this requirement.
>
> This breaks (among other things) KVM guests that have PtrAuth enabled,
> while the hypervisor doesn't want to expose the feature to its guest.
> To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in this
> case), and masks out the unsupported feature.
>
> QEMU not honoring the trap request means that the guest observes
> that the feature is present in the HW, starts using it, and dies
> a horrible death when KVM injects an UNDEF, because the feature
> *really* isn't supported.
>
> Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.
>
> Reported-by: Will Deacon <address@hidden>
> Signed-off-by: Marc Zyngier <address@hidden>
> ---
> There is a number of other trap bits missing (TID[0-2], for example),
> but this at least gets a mainline Linux going with cpu=max.
BTW, Peter, this appears to have been the bug that was causing me so many
problems on my VHE branch. Probably *exactly* this bug wrt ptrauth, since that
would also be included with -cpu max.
I am now able to boot a kvm guest kernel to the point of the no rootfs panic,
which I wasn't before.
I can only think that I mis-identified the true cause in Lyon.
Anyway, thanks Marc!
r~
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements, Richard Henderson, 2019/11/26
Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements,
Richard Henderson <=