Date: Wed, 21 Apr 2021 00:40:22 +0000 From: Greg V <greg@unrelenting.technology> To: freebsd-arm@freebsd.org, Michael Tuexen <tuexen@freebsd.org>, Dmitry Skorodumov <sdmitry@parallels.com> Subject: Re: gic-v2 and SGI interrupts on boot CPU Message-ID: <13A8B0FE-6300-4980-8DA9-49C7A37840CC@unrelenting.technology> In-Reply-To: <2B7A227B-245F-4F1B-A700-263C3FE56B68@freebsd.org> References: <YQXPR01MB4691AB59B8CFBE3521B8002EA1489@YQXPR01MB4691.CANPRD01.PROD.OUTLOOK.COM> <2B7A227B-245F-4F1B-A700-263C3FE56B68@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 20, 2021 10:38:44 PM UTC, Michael Tuexen <tuexen@freebsd=2Eorg> w= rote: >> On 21=2E Apr 2021, at 00:02, Dmitry Skorodumov via freebsd-arm <freebsd= -arm@freebsd=2Eorg> wrote: >>=20 >> Hi >>=20 >>=20 >> It looks like code for gic-v2 in FreeBSD not quite correctly relies on = implementation defined behaviour of GIC=2E >>=20 >> The g<file:///Users/sdmitry/Downloads/IHI0048B_b_gic_architecture_spec= ification=2Epdf>ic 2=2E0 spec https://developer=2Earm=2Ecom/documentation/i= hi0048/bb chapter 3=2E2=2E2 "Interrupt controls in the GIC" states the foll= owing: >>=20 >> "Whether SGIs are permanently enabled, or can be enabled and disabled b= y writes to the GICD_ISENABLERn and GICD_ICENABLERn, is IMPLEMENTATION DEFI= NED=2E" >>=20 >> But code in sys/arm/arm/gic=2Ec assumes that SGI are always enabled and= doesn't configure them at initialization=2E They are initialized only for = secondary CPUs - in arm_gic_init_secondary()=2E >>=20 >> 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)=2E And even = if platform supports only gic-v2, likely SGIs are always enabled anyway=2E = So, my post is rather pedantic notice without real life case=2E >Dear all, > >if I understand things correctly, the problem described is the cause whic= h does not >allow to use more than one CPU core in FreeBSD when running on Parallels = Desktop on >an M1 based Mac=2E It runs perfectly well with one core, but with multipl= e cores it >locks up during boot=2E Hmm if I'm reading it correctly, the gicv2 driver *does* do this on second= ary CPUs, just not on the boot one=2E Which doesn't sound like something th= at would cause SMP boot to break but single-core to still work=2E Seems like people using QEMU with Hypervisor=2Eframework patches do have S= MP working fine: https://gist=2Egithub=2Ecom/ctsrc/a1f57933a2cde9abc0f07be12889f97f so go b= other Parallels about their bugs ;)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13A8B0FE-6300-4980-8DA9-49C7A37840CC>