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!