On 2011-12-06 19:13, Michael Tokarev wrote: > On 06.12.2011 20:57, Michael Tokarev wrote: >> On 06.12.2011 20:38, Jan Kiszka wrote: >>> On 2011-12-06 17:29, Michael Tokarev wrote: >> [] >>>> It appears there are two issues here, one is fixed by >>>> 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and >>>> another bisect leads to this commit: >> >> Or 3... :) >> >>>> commit 59539c913383fdd3350681301b44f02fa7ee2757 >>>> Author: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >>>> Date: Mon Jun 27 12:22:28 2011 +0200 >>>> >>>> qemu-kvm: Fix in-kernel PIC reset >> >> [] >>>> Anything wrong with this patch? >>> >>> I tend to say "no". It may just reveals some issue elsewhere. >>> >>> To cross-check: Does this series [1] expose the same issue with vanilla >>> QEMU when enabling that in-kernel irqchip version? >> >> I cross-checked it the other way, which really should have been done >> at the very beginning instead of wasting so much time of so many >> people at once. I just tried qemu-kvm-1.0, which I wasn't due to >> an unrelated issue (1.0 does not work for me in my funky 32/64bit >> environment). Also, since the bug has been reported especially >> against 0.15 version (triggering by upgrading from 0.14 to 0.15), >> I didn't insist on trying 1.0, which was my biggest mistake. >> >> And in qemu-kvm-1.0, the problem guest Just Works. So i t must be >> something else which were fixed between 0.15 and 1.0. > > For the 0.15 .. 1.0 change, the first commit which restores the (broken > in 0.15) functionality is this one: > > commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8 > Author: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > Date: Fri Oct 7 09:19:45 2011 +0200 > > i8259: Clear ELCR on reset > > The ELCR is actually part of the chipset but we model it here for > simplicity reasons. The PIIX3 clears the ELCR on reset, which was once > broken by 4dbe19e181. Fix this by splitting up pic_init_reset from > pic_reset and clearing the register in the latter. > > Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > Signed-off-by: Blue Swirl <blauwirbel@xxxxxxxxx> > > Which is quite expected having in mind the commit which "broke" > it for 0.15. Yep, makes a lot of sense. That patch should be applied to stable then (who's in charge?). > >> Upstream qemu 1.0 does not have this issue too. >> >>> [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871 >> >> I'll try to verify this series in a moment, but hopefully it will work >> fine too :) > > And that turned out to be not so easy for me. Which is this > series against? Is there may be a git tree with this series > applied already? Oops. It's against qemu-kvm's uq/master queue. Find a git tree at git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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