From: Marc Zyngier <maz@kernel.org>
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [BUG] arm64/m1: Accessing SYS_ID_AA64ISAR2_EL1 causes early boot failure on 5.15.28, 5.16.14, 5.17
Date: Mon, 14 Mar 2022 10:34:05 +0000 [thread overview]
Message-ID: <907327093697278cd816aafec9e20b3e@kernel.org> (raw)
In-Reply-To: <2498FEAE-DE38-46C5-A50A-93396BB0938A@adelielinux.org>
{switching email address]
On 2022-03-14 10:03, A. Wilcox wrote:
> On Mar 14, 2022, at 4:08 AM, Marc Zyngier <maz@misterjones.org> wrote:
>> On 2022-03-14 06:35, Greg KH wrote:
>>> On Sun, Mar 13, 2022 at 10:59:01PM -0500, A. Wilcox wrote:
>>>> Hello,
>>>> I’ve been testing kernel updates for the Adélie Linux distribution’s
>>>> ARM64 port using a Parallels VM on a MacBook Pro (13-inch, M1,
>>>> 2020).
>>>> When the kernel attempts to access SYS_ID_AA64ISAR2_EL1, it causes a
>>>> fault as seen here booting 5.17.0-rc8:
>>
>> […]
>>
>>>> This is because detection of the clearbhb instruction support
>>>> requires
>>>> accessing SYS_ID_AA64ISAR2_EL1. Commenting out the two uses of
>>>> supports_clearbhb in the kernel now yields a successful boot.
>>>> Qemu developers seem to have found this issue as well[1] when trying
>>>> to
>>>> boot 5.17 using HVF, the Apple Hypervisor Framework. This seems to
>>>> be
>>>> some sort of platform quirk on M1, or at least in HVF on M1. I’m not
>>>> sure what the best workaround would be for this.
>>>> SYS_ID_AA64ISAR2_EL1
>>>> seems to be something added in ARMv8.7, so perhaps access to it
>>>> could be
>>>> gated on that.
>>>> Unfortunately, this code was just added to 5.15.28 and 5.16.14, so
>>>> stable no longer boots on Parallels VM on M1. I am unsure if this
>>>> affects physical boot on Apple M1 or not.
>>> What commit causes this problem? It sounds like you narrowed this
>>> down
>>> already, right?
>>
>> This really is a Parallels bug. These kernels run fine on bare metal
>> M1 and in KVM. QEMU was affected as well, and that was fixed in their
>> HVF handling. HVF itself is fine.
>>
>> So this should be punted back to the hypervisor vendor for not
>> properly
>> implementing the architecture (no ID register is allowed to UNDEF).
>
> Thanks, I wasn’t able to test native boot. Since this is a bug in the
> hypervisor, I’ll notify them in the morning.
Great, thanks.
> For those of us stuck with Parallels, I’ll assume reverting of these
> three commits in my own build is the best way forward until it’s
> fixed. The M1 isn’t going to grow new instruction support in the
> meantime, so I don’t see a whole lot of harm in it - but the other
> mitigations in .28 seem useful.
As a *very* short term solution, that's probably the right thing to do.
However, this register is bound to grow new uses over time, and
disabling
these features in a distro kernel is going to impact all users, unless
your particular kernel build is strictly limited to M1.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2022-03-14 10:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 3:59 [BUG] arm64/m1: Accessing SYS_ID_AA64ISAR2_EL1 causes early boot failure on 5.15.28, 5.16.14, 5.17 A. Wilcox
2022-03-14 6:35 ` Greg KH
2022-03-14 9:08 ` Marc Zyngier
2022-03-14 10:03 ` A. Wilcox
2022-03-14 10:34 ` Marc Zyngier [this message]
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=907327093697278cd816aafec9e20b3e@kernel.org \
--to=maz@kernel.org \
--cc=awilfox@adelielinux.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).