x86: change signatures of ipi_{bitmap,swi}_handler() to take pointer
ClosedPublic
Actions

Authored by kib on Mar 6 2026, 12:02 AM.

Details

Reviewers

markj
jhb

Commits

rGfdc1f3450634: x86: change signatures of ipi_{bitmap,swi}_handler() to take pointer

Summary

instead of the frame itself.  It is some stretch of the amd64 ABI, and
is not easily fullfilled when handlers are called from C and not asm.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

kib created this revision.Mar 6 2026, 12:02 AM

Herald added a subscriber: imp. · View Herald TranscriptMar 6 2026, 12:02 AM

kib requested review of this revision.Mar 6 2026, 12:02 AM

markj accepted this revision.Mar 7 2026, 12:22 AM

This revision is now accepted and ready to land.Mar 7 2026, 12:22 AM

Closed by commit rGfdc1f3450634: x86: change signatures of ipi_{bitmap,swi}_handler() to take pointer (authored by kib). · Explain WhyMar 7 2026, 3:59 AM

This revision was automatically updated to reflect the committed changes.

kib added a commit: rGfdc1f3450634: x86: change signatures of ipi_{bitmap,swi}_handler() to take pointer.

Herald added a subscriber: ehem_freebsd_m5p.com. · View Herald TranscriptMar 7 2026, 3:59 AM

Drat. Phabricator flagged me due to the Xen changes, but I didn't look too closely since it seemed neutral.

I've gotten the impression trap frames are being passed around too much. I think curthread should be updated rather closer to the handler and not at intr_event_execute_handlers(). Updating at intr_event_execute_handlers() causes problems for cascading PICs since they go through the function twice. This isn't too much of a problem on x86 since only Xen uses the functionality (a proper driver for Hyper-V likely would too, Bhyve may want in the future). For other architectures it is a real problem.

Notice Github #1748 (this was proposed a while back, I'm unsure of the last 2 commits and the clock path needs checking).