Page MenuHomeFreeBSD

Improve generic_timer startup on secondary cores
AbandonedPublic

Authored by wma_semihalf.com on Jul 20 2015, 6:43 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 17, 7:04 AM
Unknown Object (File)
Sun, Mar 24, 6:12 PM
Unknown Object (File)
Feb 23 2024, 3:23 PM
Unknown Object (File)
Jan 19 2024, 12:57 AM
Unknown Object (File)
Dec 20 2023, 3:05 AM
Unknown Object (File)
Nov 13 2023, 1:30 PM
Unknown Object (File)
Oct 25 2023, 9:00 AM
Unknown Object (File)
Oct 7 2023, 10:41 PM
Subscribers

Details

Summary

By default the PPI are masked when the secondary CPU is started. Implement a method to allow unmasking this previously configured interrupt. This approach is more elegant than the one in GICv2, where the TMR PPIs are hardcoded in gic_init_secondary routine.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

wma_semihalf.com retitled this revision from to Improve generic_timer startup on secondary cores.
wma_semihalf.com updated this object.
wma_semihalf.com edited the test plan for this revision. (Show Details)
wma_semihalf.com set the repository for this revision to rS FreeBSD src repository - subversion.

I would prefer if we did something like the proposal I posted to arch, https://lists.freebsd.org/pipermail/freebsd-arch/2015-July/017270.html. It allows us to mark interrupts as needing to be unmasked on all cpus.

I like the idea of doing sth generic. What is your ETA on this?
If it takes more than 2-3 weeks maybe it'd be good to submit anything that gives us support for PPIs and revert it once an elegant solution is done? I mean this patch or even port an ugly hack from gic.c, whatever, since it'd be only temporary. Without this, the GICv3 combined with SMP is pretty useless.
Andrew, Ed, what do you think?

I like the idea of doing sth generic. What is your ETA on this?
If it takes more than 2-3 weeks maybe it'd be good to submit anything that gives us support for PPIs and revert it once an elegant solution is done? I mean this patch or even port an ugly hack from gic.c, whatever, since it'd be only temporary. Without this, the GICv3 combined with SMP is pretty useless.

I tend to agree with you. I really want to see all of the changes necessary to support ThunderX as soon as possible, as we'll soon have new silicon in the Sentex colo and can then open the system up to wider use. But it really comes down the potential timeline for the final solution.

As discussed with Ed, a simpler temporary workaround will be added to gicv3.