Messages in this thread | | | Date | Mon, 14 Mar 2022 10:34:05 +0000 | From | Marc Zyngier <> | Subject | Re: [BUG] arm64/m1: Accessing SYS_ID_AA64ISAR2_EL1 causes early boot failure on 5.15.28, 5.16.14, 5.17 |
| |
{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...
| |