amd64: move code to check for traps with interrupts disabled into helpers

[kib]

Restore PSL_I check for kernel.
Add break to default case.
Decrease nesting.

[jhb]

Given the check for interrupts being disabled is in the new hooks, I wonder if the name should reflect that? I also think spelling out user vs kernel would be more readable? Maybe trap_check_intr_user or something? Not that the name matters tremendously.

sys/amd64/amd64/trap.c

253

I think we don't actually enable interrupts for the userspace traps anymore (so this comment is a bit stale). Maybe take this opportunity to update the comments a bit? Something like:

/*
  * Warn with a message on the user's tty if application code
  * has disabled interrupts and then trapped.
  */
static void
trap_intr_dis_u(...)
....

/*
  * Some traps such as NMIs and debugging faults can be
  * taken in the kernel while interrupts are disabled.
  * Other traps shouldn't occur with interrupts disabled
  * unless the kernel has a bug.  Re-enable interrupts
  * in case this occurs (unless the interrupted thread holds
  * a spin lock.
  */
static void
trap_intr_dis_k(...)

I'm not convinced that the enable_intr() call is actually useful btw, and I haven't seen it trigger in practice in quite a long while. I would sort of be inclined to drop it. Probably we are about to panic anyway.

I don't think the userspace version can happy very easily (I think with i386 if you opened /dev/io and your TSS had I/O permission you could disable interrupts in userspace, but I don't think that's a thing on amd64 IIRC).

[kib]

sys/amd64/amd64/trap.c

253

The kernel case can be triggered for sure, e.g. by loading invalid segments, non-canonical segment bases, or by constructing the iretq frame that traps.

In all these cases, we do not panic, and we call into the normal C code like trapsignal(). There, the interrupts must be enabled for sure.

For userspace, I agree with you, but this should be a separate change if ever do it.

[kib]

Rename functions.
Rewrite comments, taking the text from the John' suggestion.

[markj]

sys/amd64/amd64/trap.c

261

You might put a branch hint here.

283

Same here, though kernel traps are less frequent.

[kib]

Add branch prediction hints.