On 17/12/2014 04:46, Wincy Van wrote: > Hi, all: > > The patchset (https://lkml.org/lkml/2014/3/18/309) fixed migration of > Windows guests, but commit 0bc830b05c667218d703f2026ec866c49df974fc > (KVM: ioapic: clear IRR for edge-triggered interrupts at delivery) > introduced a bug (see > https://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg109813.html). > > From the description "Unlike the old qemu-kvm, which really never did > that, with new QEMU it is for some reason > somewhat likely to migrate a VM with a nonzero IRR in the ioapic." > > Why could new QEMU do that? I can not find any codes about the "some reason".. > As we know, once a irq is set in kvm's ioapic, the ioapic will send > that irq to lapic, this is an "atomic" operation. It can happen if the IRQ is masked in the IOAPIC, for example. Until commit 0bc830b, KVM could not distinguish two cases: 1) an edge-triggered interrupt that was raised while the IOAPIC had it masked 2) an edge-triggered interrupt that was raised and delivered, but for which userspace left the level to 1. > Then, kvm will inject them in inject_pending_event(or set rvi in > apic-v case). QEMU will also save the pending irq when doing > migration. No, QEMU does not save the pending IRQ. IRQs are stateless in QEMU. The assumption is that after a qemu_set_irq the IRQ will be delivered---possibly on the other side of the migration, but it will be delivered. Paolo > I can not find a point which guest could lose a irq, but this scenario > really exists. > > Any ideas? > > > Thanks, > > Wincy > -- 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
