On 06/30/2009 10:36 PM, Eric W. Biederman wrote:
The short version is I don't know what work arounds we will ultimately
decide to deploy to work with real hardware.
I have been seriously contemplating causing a cpu hot-unplug request
to fail if we are in ioapic mode and we have irqs routed to the cpu
that is being unplugged.
Well, obviously we need to disassociate any irqs from such a cpu. Could be done
from the kernel or only enforced by the kernel.
Using the normal irq migration path we can move irqs off of a cpu reliably
there just aren't any progress guarantees.
Program the ioapic to the new cpu. Wait a few milliseconds. If it
takes more than that to get an interrupt from the ioapic to the local
apic, the machine has much bigger problems.
Even with perfectly working hardware it is not possible in the general
case to migrate an ioapic irq from one cpu to another outside of an
interrupt handler without without risking dropping an interrupt.
Can't you generate a spurious interrupt immediately after the migration? An
extra interrupt shouldn't hurt.
Nope. The ioapics can't be told to send an interrupt.
You can program the local apic ICR to generate an interrupt with the
same vector.
There is no general way to know you have seen the last interrupt
floating around your system. PCI ordering rules don't help because
the ioapics can potentially take an out of band channel.
Can you describe the problem scenario? an ioapic->lapic message delivered to a
dead cpu?
Dropped irqs.. Driver hangs because it is waiting for an irq. Hardware
hangs because it is waiting for the cpu to process the irq.
Potentially we get a level triggered irq that is never acked by
the cpu that won't arm until the cpu send an ack, and we can't
send an ack from another cpu.
I think a spurious interrupt generated through the local apic solves
that problem. For level-triggered interrupts, mask them before
offlining the cpu.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
