Avi Kivity <avi@xxxxxxxxxx> writes: > On 06/30/2009 10:08 PM, Eric W. Biederman wrote: >>> Can you elaborate? For kvm guests, the hardware is reasonably will implemented >>> and if not we will fix it. We need not cripple a feature just because some >>> hardware is broken. >>> >> >> 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. >> 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. >> 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. Eric -- 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
