Peter Maydell <peter.mayd...@linaro.org> writes: > On 12 March 2015 at 15:51, Peter Maydell <peter.mayd...@linaro.org> wrote: >> On 4 March 2015 at 14:35, Alex Bennée <alex.ben...@linaro.org> 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.
Fair enough - I'll drop this patch on the re-spin > > -- PMM -- Alex Bennée _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
