Bug 258136 - panic on boot under ARM64 Parallels, unless set to Other
Summary: panic on boot under ARM64 Parallels, unless set to Other
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-29 09:40 UTC by Edward Tomasz Napierala
Modified: 2021-09-16 15:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edward Tomasz Napierala freebsd_committer 2021-08-29 09:40:04 UTC
When trying to boot FreeBSD 14-CURRENT under Parallels running on M1 Macbook, it panics like this (hand-transcribed):

gicv2m0: <ARM Generic Interrupt Controller MSI/MSIX> mem 0x2250000-0x2250ff on gic0
panic: arm_gic_reserve_msi_range: MSI interrupt 64 already has a handler

The workaround is to set the virtual machine type to "Other"; the above happens when set to Windows or Linux.

One curious difference between dmesg output in working/not working case is this line:

gic0: pn 0x0, arch 0x2, rev 0x0, implementer 0x0 irqs 128

It appears when it works (VM type set to Other); it does not appear when it panics.
Comment 1 Andrew Turner freebsd_committer 2021-09-01 09:50:50 UTC
This should be fixed with https://reviews.freebsd.org/D31767 and https://reviews.freebsd.org/D31768
Comment 2 commit-hook freebsd_committer 2021-09-14 10:43:11 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=e4d89a633e3b31ec1319e3238abceee2048996c4

commit e4d89a633e3b31ec1319e3238abceee2048996c4
Author:     Andrew Turner <andrew@FreeBSD.org>
AuthorDate: 2021-09-01 09:41:14 +0000
Commit:     Andrew Turner <andrew@FreeBSD.org>
CommitDate: 2021-09-14 07:24:52 +0000

    Add support for gicv2m as a child of gicv3

    On some systems, e.g. Parallels set to host a Linux VM under an M1 Mac,
    there is a GICv2m as a child of the GICv3. We previously assumed the
    GICv2m was always a child of a GICv2. Fix this by adding the needed
    support to the GICv3 driver.

    PR:             258136
    Reported by:    trasz
    Sponsored by:   The FreeBSD Foundation
    Differential Revision: https://reviews.freebsd.org/D31768

 sys/arm64/arm64/gic_v3.c     | 90 ++++++++++++++++++++++++++++++++++++++++----
 sys/arm64/arm64/gic_v3_fdt.c |  2 +-
 2 files changed, 83 insertions(+), 9 deletions(-)
Comment 3 commit-hook freebsd_committer 2021-09-14 10:43:12 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=c6f3076d44055f7b02467ce074210f73d0ce0ef6

commit c6f3076d44055f7b02467ce074210f73d0ce0ef6
Author:     Andrew Turner <andrew@FreeBSD.org>
AuthorDate: 2021-09-01 09:39:01 +0000
Commit:     Andrew Turner <andrew@FreeBSD.org>
CommitDate: 2021-09-14 07:24:52 +0000

    Move the GICv2m msi handling to the parent

    This is in preperation for adding support for the GICv2m driver as a
    child of the GICv3 driver.

    PR:             258136
    Reported by:    trasz
    Sponsored by:   The FreeBSD Foundation
    Differential Revision: https://reviews.freebsd.org/D31767

 sys/arm/arm/gic.c        | 296 ++++++++++++++++++++++++++++++-----------------
 sys/arm/arm/gic.h        |   8 +-
 sys/arm/arm/gic_common.h |   4 +
 3 files changed, 195 insertions(+), 113 deletions(-)
Comment 4 Edward Tomasz Napierala freebsd_committer 2021-09-16 14:47:01 UTC
Also see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258534 for a similar, but different, problem.