Re: gic-v2 and SGI interrupts on boot CPU
Michael Tuexen <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
> On 21. Apr 2021, at 02:40, Greg V <[email protected]> wrote: > > > > On April 20, 2021 10:38:44 PM UTC, Michael Tuexen <[email protected]> wrote: >>> On 21. Apr 2021, at 00:02, Dmitry Skorodumov via freebsd-arm <[email protected]> wrote: >>> >>> Hi >>> >>> >>> It looks like code for gic-v2 in FreeBSD not quite correctly relies on implementation defined behaviour of GIC. >>> >>> The g<file:///Users/sdmitry/Downloads/IHI0048B_b_gic_architecture_specification.pdf>ic 2.0 spec https://developer.arm.com/documentation/ihi0048/bb chapter 3.2.2 "Interrupt controls in the GIC" states the following: >>> >>> "Whether SGIs are permanently enabled, or can be enabled and disabled by writes to the GICD_ISENABLERn and GICD_ICENABLERn, is IMPLEMENTATION DEFINED." >>> >>> But code in sys/arm/arm/gic.c assumes that SGI are always enabled and doesn't configure them at initialization. They are initialized only for secondary CPUs - in arm_gic_init_secondary(). >>> >>> For sure it is a rather minor issue, since all appears to be ok in gic-v3 (v3 code enables SGIs for all CPUs, including the boot one). And even if platform supports only gic-v2, likely SGIs are always enabled anyway. So, my post is rather pedantic notice without real life case. >> Dear all, >> >> if I understand things correctly, the problem described is the cause which does not >> allow to use more than one CPU core in FreeBSD when running on Parallels Desktop on >> an M1 based Mac. It runs perfectly well with one core, but with multiple cores it >> locks up during boot. > > Hmm if I'm reading it correctly, the gicv2 driver *does* do this on secondary CPUs, just not on the boot one. Which doesn't sound like something that would cause SMP boot to break but single-core to still work. > > Seems like people using QEMU with Hypervisor.framework patches do have SMP working fine: > https://gist.github.com/ctsrc/a1f57933a2cde9abc0f07be12889f97f so go bother Parallels about their bugs ;) I reported the issue in https://forum.parallels.com/threads/freebsd-support.352663/ and Dmitry said that they found the issue and fixed it within Parallels, so FreeBSD 13 will be supported by a future update of Parallels. But since the cause is based on an implementation depended behaviour and FreeBSD seems to assume one particular one, I suggested to report it here. So I think the argument that there is some platform, which works, does not imply that the FreeBSD behaviour is correct. As Vincent figured out, a potential fix for FreeBSD is in https://reviews.freebsd.org/D26975. I can't comment on if the patch is architecturally correct, I can confirm that it resolves the problem. Best regards Michael _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"