On Sunday 28 September 2008 13:04:06 Avi Kivity wrote: > Tian, Kevin wrote: > >> No. Maybe the Neocleus polarity trick (which also reduces performance). > > > > To my knowledge, Neocleus polarity trick can't solve this isolation > > issue, which just provides one effecient way to track > > assertion/deassertion transition on the irq line. For example, reverse > > polarity when receiving an instance, and then a new irq instance would > > occur when all devices de- assert on shared irq line, and then recover > > the polarity. In your concerned case where guest driver misbehaves, this > > polarity trick can't work neither as one device always asserts the line. > > You're right, I didn't think it through. > > If there was a standard way to mask pci irqs, it might have worked, but > there isn't, unfortunately. > One purpose:
If we suffered from IRQ storm of one level triggered irq line, two possible: host issue or guest issue. If it's a host issue, host should try to stop it. If it can't, the IRQ line would be disabled, and guest device also isn't functional. If it's a guest issue, guest should try to stop it, and prevent it from causing trouble in host. KVM should try best including disable guest device to do this. So guest device also won't functional. Base on above theory, we can assume that IRQ storm caused by assigned guest device, and try to stop device from doing this. (Yeah, anyway, guest device won't survive). I think we can brought a little QoS concept here(stolen from Eddie :) ). The assumption is, the normal rate of device deliver interrupts is much slower than a continuous level trigger if the EOI is wrote immediately. So we can do something with the gap. Measure the calling rate of our irq handler, if it's exceed some reasonable threshold, KVM would try to stop guest device for a while (even it don't know if the guest device cause this). First to try set interrupt disable bit in Device Control Register, wait for a period of time, then check again. If the irq strom can't be stopped, KVM try a more aggressive way: Do the Function Level Reset. It's should be the end of device's life... Oh, of course, if even FLR didn't solve the IRQ storm, that's host's issue. Let's wait host to disable the IRQ line - of course, the guest device can't be recovered too. It's just a initial purpose, I think it may work. The problem is if the gap is easy to catch... But at least, I think a physical continuous one should be much different from any working ones... -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
