From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.bennee@linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=) Date: Fri, 13 Mar 2015 10:38:58 +0000 Subject: [PATCH v2 3/6] hw/char: pl011 don't keep setting the IRQ if nothing changed In-Reply-To: References: <1425479753-18349-1-git-send-email-alex.bennee@linaro.org> <1425479753-18349-4-git-send-email-alex.bennee@linaro.org> Message-ID: <87ioe5b2rh.fsf@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Peter Maydell writes: > On 12 March 2015 at 15:51, Peter Maydell wrote: >> On 4 March 2015 at 14:35, Alex Benn?e 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