Peter Maydell [off-list ref] writes:

On 12 March 2015 at 15:51, Peter Maydell [off-list ref] wrote:

quoted

On 4 March 2015 at 14:35, Alex Benn?e [off-list ref] wrote:

quoted

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.

quoted

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