From: Richard Henderson <richard.henderson@linaro.org>
To: Marc Zyngier <maz@kernel.org>, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
Date: Tue, 26 Nov 2019 21:04:16 +0000 [thread overview]
Message-ID: <11f7be55-a53d-bab1-c2e6-edbca1abb554@linaro.org> (raw)
In-Reply-To: <20191123115618.29230-1-maz@kernel.org>
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 <will@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> 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~
WARNING: multiple messages have this Message-ID (diff)
From: Richard Henderson <richard.henderson@linaro.org>
To: Marc Zyngier <maz@kernel.org>, qemu-devel@nongnu.org
Cc: Will Deacon <will@kernel.org>, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements
Date: Tue, 26 Nov 2019 21:04:16 +0000 [thread overview]
Message-ID: <11f7be55-a53d-bab1-c2e6-edbca1abb554@linaro.org> (raw)
In-Reply-To: <20191123115618.29230-1-maz@kernel.org>
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 <will@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> 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~
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2019-11-26 21:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-23 11:56 [PATCH] target/arm: Honor HCR_EL2.TID3 trapping requirements Marc Zyngier
2019-11-23 11:56 ` Marc Zyngier
2019-11-25 10:40 ` Will Deacon
2019-11-25 10:40 ` Will Deacon
2019-11-25 10:59 ` Marc Zyngier
2019-11-25 10:59 ` Marc Zyngier
2019-11-25 16:21 ` Peter Maydell
2019-11-25 16:21 ` Peter Maydell
2019-11-25 17:08 ` Marc Zyngier
2019-11-25 17:08 ` Marc Zyngier
2019-11-25 17:27 ` Peter Maydell
2019-11-25 17:27 ` Peter Maydell
2019-11-25 17:49 ` Marc Zyngier
2019-11-25 17:49 ` Marc Zyngier
2019-11-26 12:46 ` Peter Maydell
2019-11-26 12:46 ` Peter Maydell
2019-11-26 10:12 ` Richard Henderson
2019-11-26 10:12 ` Richard Henderson
2019-11-26 13:19 ` Peter Maydell
2019-11-26 13:19 ` Peter Maydell
2019-11-26 21:04 ` Richard Henderson [this message]
2019-11-26 21:04 ` Richard Henderson
2019-11-27 9:13 ` Marc Zyngier
2019-11-27 9:13 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11f7be55-a53d-bab1-c2e6-edbca1abb554@linaro.org \
--to=richard.henderson@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.