mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@misterjones.org>
To: Greg KH <gregkh@linuxfoundation.org>,
	"A. Wilcox" <awilfox@adelielinux.org>
Cc: 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 09:08:42 +0000	[thread overview]
Message-ID: <1f0b74caa45a1d73af68eab8dcc15485@misterjones.org> (raw)
In-Reply-To: <Yi7iRSHaFGsYup1p@kroah.com>

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).

         M.
-- 
Who you jivin' with that Cosmik Debris?

  reply	other threads:[~2022-03-14  9:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  3:59 A. Wilcox
2022-03-14  6:35 ` Greg KH
2022-03-14  9:08   ` Marc Zyngier [this message]
2022-03-14 10:03     ` A. Wilcox
2022-03-14 10:34       ` 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=1f0b74caa45a1d73af68eab8dcc15485@misterjones.org \
    --to=maz@misterjones.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

all inboxes | Powered by JetHome®