x86: locking when messing with the PIC
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 25 Oct 2013 21:43:13 +0000 (14:43 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 16 Jan 2014 19:16:49 +0000 (11:16 -0800)
commit6c5b14764f757c4c3253cad0d7aa3e099733ca90
treee8e6f236e70a685e18e72c19e0ef10d5343ed6fc
parentaf67501213f89e68c754648d9c7fd51556891df3
x86: locking when messing with the PIC

This is ultra-paranoia.  In general, we only mess with the PIC from
core 0.  That's the only core we route PIC IRQs to.  But there's a
chance we have an MCP that triggers something like a mask or unmask of
the PIC, which could happen concurrently with an IRQ.  I don't know if
we have anything that can do that yet, but better safe than sorry.

As far as the extra perf overheads go, ideally we wouldn't even be using
the PIC, but we'd have the same set of issues with the IOAPIC, and will
need locking in those cases too.
kern/arch/x86/apic.c
kern/arch/x86/apic.h