On 12 March 2015 at 15:51, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > On 4 March 2015 at 14:35, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: >> While observing KVM traces I can see additional IRQ calls on pretty much >> every MMIO access which is just plain inefficient. Only update the QEMU >> IRQ level if something has actually changed from last time. Otherwise we >> may be papering over other failure modes. > Consider this sequence of events: Incidentally, the code review rule of thumb that led me to construct that scenario is: * state inside the device struct which doesn't correspond to real hardware state is suspicious * state which doesn't have any handling on migration save/restore is doubly suspicious ...and then it was just a matter of "find the situation where this is broken" :-) If we want to avoid making syscalls back into KVM it might be better to attack the problem in the GIC object rather than in all the devices that might be connected to it. In general QEMU devices tend to assume they can just always call qemu_set_irq() and it's the other end's job to avoid doing anything too expensive in that situation. -- PMM -- 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
