| Message ID | 20111206122752.GA31385@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 06.12.2011 16:27, Michael S. Tsirkin wrote: > On Tue, Dec 06, 2011 at 03:02:49PM +0400, Michael Tokarev wrote: [] >> And after applying Avi's instructions here's the real bisect >> result: >> >> ab431c283e7055bcd6fb622f212bb29e84a6a134 is the first bad commit >> commit ab431c283e7055bcd6fb622f212bb29e84a6a134 >> Author: Isaku Yamahata <yamahata@valinux.co.jp> >> Date: Fri Apr 1 20:43:23 2011 +0900 >> >> piix_pci: optimize set irq path > > Could you try with this commit reverted please? > Reverting patch below. Warning: compiled only. After some discussion on IRC, here's a summary. I applied this patch on top of qemu-kvm-0.15.0. The resulting executable shows the same bad behavour with my test guest as it was without this patch. So apparently just reverting this patch isn't enough for the problem to go away. But when doing a bisection, the result is very reliable - it always points to the commit above (which we tried to revert by this patch). More data points (all against qemu-kvm-0.15.0). First, as Avi pointed out, this patch references PIC which is used by standardPC HAL and not used by ACPI HAL. So it might be something to think about, at least. Now, so far, all deviecs which are on IRQ11 are affected. When enabling USB and NIC, they both gets assigned to IRQ11 and both does not work. When enabling just one of them (either), only that device (which gets assigned to IRQ11) does not work. All other devices apparently works fine (including PS/2 Mouse on IRQ12). When using just one of NIC/USB, all IRQs in the guest becomes single-device, so IRQ sharing isn't a problem. I wasn't able to force the guest to use IRQ10 so far (to verify). Also, when booted with -no-kvm-irqchip, guest Just Works, including USB and NIC sharing IRQ11. While on IRC there was one more person who suffered from the same issue, now with Win2003. He was able to solve his guest issue by changing StandardPC HAL into ACPI HAL, using a "hackish" way (by replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found on win2k3 installation CDROM). I wasn't able to replace stdhal into anything else on my test winXP machine - after changing HAL.DLL, on next reboot my guest complains about being unable to find boot device (BSOD STOP 0x7b) - despite using stdIDE and mergeide. I'll investigate the guest side further later. When in this funky mode with non-working IRQ11 (when a NIC (rtl8139) is assigned to it), winXP guest shows huge delays when trying to open "My Computer" properties - it freezes for 30..40 seconds after hitting "Properties" in the context menu. I can only guess it is trying to do something with the IRQs at that time, which does not work. I wasn't able to (quickly) find a tool for winXP to show IRQ statistics. That's about all the info so far which I know about this issue. Thanks, /mjt
[Added Jan Kiszka to Cc] On 06.12.2011 18:45, Michael Tokarev wrote: [complete thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705] > More data points (all against qemu-kvm-0.15.0). > > First, as Avi pointed out, this patch references PIC which is > used by standardPC HAL and not used by ACPI HAL. So it might > be something to think about, at least. > > Now, so far, all deviecs which are on IRQ11 are affected. When > enabling USB and NIC, they both gets assigned to IRQ11 and both > does not work. When enabling just one of them (either), only > that device (which gets assigned to IRQ11) does not work. All > other devices apparently works fine (including PS/2 Mouse on > IRQ12). > > When using just one of NIC/USB, all IRQs in the guest becomes > single-device, so IRQ sharing isn't a problem. > > I wasn't able to force the guest to use IRQ10 so far (to verify). > > Also, when booted with -no-kvm-irqchip, guest Just Works, including > USB and NIC sharing IRQ11. > > While on IRC there was one more person who suffered from the same > issue, now with Win2003. He was able to solve his guest issue by > changing StandardPC HAL into ACPI HAL, using a "hackish" way (by > replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found > on win2k3 installation CDROM). I wasn't able to replace stdhal > into anything else on my test winXP machine - after changing HAL.DLL, > on next reboot my guest complains about being unable to find boot > device (BSOD STOP 0x7b) - despite using stdIDE and mergeide. I'll > investigate the guest side further later. > > When in this funky mode with non-working IRQ11 (when a NIC (rtl8139) > is assigned to it), winXP guest shows huge delays when trying to > open "My Computer" properties - it freezes for 30..40 seconds after > hitting "Properties" in the context menu. I can only guess it is > trying to do something with the IRQs at that time, which does not > work. I wasn't able to (quickly) find a tool for winXP to show > IRQ statistics. > > That's about all the info so far which I know about this issue. It appears there are two issues here, one is fixed by 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and another bisect leads to this commit: commit 59539c913383fdd3350681301b44f02fa7ee2757 Author: Jan Kiszka <jan.kiszka@siemens.com> Date: Mon Jun 27 12:22:28 2011 +0200 qemu-kvm: Fix in-kernel PIC reset Lacking sync of the user space state to the kernel after system reset left the PIC behind in an undefined state. This broke IRQ delivery in some scenarios, e.g. when resetting while in the BIOS. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com> Reverting this single commit on top of 0.15.0 fixes the guest issues described in this thread. This commit is qemu-kvm-specific (and indeed, the issue only affects qemu-kvm). Note also that as per above, -no-kvm-irqchip fixes the guest issue too. Anything wrong with this patch? Thanks, /mjt
On 2011-12-06 17:29, Michael Tokarev wrote: > [Added Jan Kiszka to Cc] > > On 06.12.2011 18:45, Michael Tokarev wrote: > [complete thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705] > >> More data points (all against qemu-kvm-0.15.0). >> >> First, as Avi pointed out, this patch references PIC which is >> used by standardPC HAL and not used by ACPI HAL. So it might >> be something to think about, at least. >> >> Now, so far, all deviecs which are on IRQ11 are affected. When >> enabling USB and NIC, they both gets assigned to IRQ11 and both >> does not work. When enabling just one of them (either), only >> that device (which gets assigned to IRQ11) does not work. All >> other devices apparently works fine (including PS/2 Mouse on >> IRQ12). >> >> When using just one of NIC/USB, all IRQs in the guest becomes >> single-device, so IRQ sharing isn't a problem. >> >> I wasn't able to force the guest to use IRQ10 so far (to verify). >> >> Also, when booted with -no-kvm-irqchip, guest Just Works, including >> USB and NIC sharing IRQ11. >> >> While on IRC there was one more person who suffered from the same >> issue, now with Win2003. He was able to solve his guest issue by >> changing StandardPC HAL into ACPI HAL, using a "hackish" way (by >> replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found >> on win2k3 installation CDROM). I wasn't able to replace stdhal >> into anything else on my test winXP machine - after changing HAL.DLL, >> on next reboot my guest complains about being unable to find boot >> device (BSOD STOP 0x7b) - despite using stdIDE and mergeide. I'll >> investigate the guest side further later. >> >> When in this funky mode with non-working IRQ11 (when a NIC (rtl8139) >> is assigned to it), winXP guest shows huge delays when trying to >> open "My Computer" properties - it freezes for 30..40 seconds after >> hitting "Properties" in the context menu. I can only guess it is >> trying to do something with the IRQs at that time, which does not >> work. I wasn't able to (quickly) find a tool for winXP to show >> IRQ statistics. >> >> That's about all the info so far which I know about this issue. > > > It appears there are two issues here, one is fixed by > 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and > another bisect leads to this commit: > > commit 59539c913383fdd3350681301b44f02fa7ee2757 > Author: Jan Kiszka <jan.kiszka@siemens.com> > Date: Mon Jun 27 12:22:28 2011 +0200 > > qemu-kvm: Fix in-kernel PIC reset > > Lacking sync of the user space state to the kernel after system reset > left the PIC behind in an undefined state. This broke IRQ delivery in > some scenarios, e.g. when resetting while in the BIOS. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > Signed-off-by: Avi Kivity <avi@redhat.com> > > > Reverting this single commit on top of 0.15.0 fixes the guest issues > described in this thread. > > This commit is qemu-kvm-specific (and indeed, the issue only affects > qemu-kvm). > > Note also that as per above, -no-kvm-irqchip fixes the guest issue too. > > 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? Jan [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871
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@siemens.com> >> 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. 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 :) Thanks! /mjt
On 2011-12-06 17: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@siemens.com> >>> 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. > > Upstream qemu 1.0 does not have this issue too. Good. Would still make sense to find this change for -stable. > >> [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 :) TIA, Jan
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@siemens.com> >>> 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@siemens.com> 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@siemens.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Which is quite expected having in mind the commit which "broke" it for 0.15. > 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? Thanks! /mjt
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@siemens.com> >>>> 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@siemens.com> > 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@siemens.com> > Signed-off-by: Blue Swirl <blauwirbel@gmail.com> > > 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
On 06.12.2011 22:21, Jan Kiszka wrote: [] >> 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@siemens.com> >> 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@siemens.com> >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> >> >> 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?). I'm not sure it makes much sense to continue 0.15 at this stage. >> >>> 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 This tree does not boot for me at all (on regular x86-64 setup) - it stays in bios after "Booting from hard disk" with 100% CPU usage. /mjt
[Removed some people from the Cc list] On 06.12.2011 22:45, Michael Tokarev wrote: [] >> git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip > > This tree does not boot for me at all (on regular x86-64 setup) - > it stays in bios after "Booting from hard disk" with 100% CPU > usage. This happens since commit 1ae1cec76a205446e6b4e5600ad0af450f7c0b5e Author: Jan Kiszka <jan.kiszka@siemens.com> Date: Sun Oct 16 19:38:22 2011 +0200 ioapic: Introduce backend/frontend infrastructure for KVM reuse Also, with this commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7 Author: Jan Kiszka <jan.kiszka@siemens.com> Date: Sat Oct 15 11:49:47 2011 +0200 kvm: Introduce core services for in-kernel irqchip support the whole thing segfaults at startup: (gdb) ru -monitor stdio -m 1G -netdev type=tap,ifname=tap-kvm1,script=no,downscript=no,id=n -device rtl8139,netdev=n,mac=52:54:00:12:34:57 -drive file=/stage/win/dist/t.raw,if=ide,cache=unsafe -vga std -usbdevice tablet -enable-kvm ... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) at /build/kvm/git/hw/ioapic_common.c:92 #2 0x00005555556a0a85 in sysbus_device_init (dev=0x555556849f60, base=0x555555be7200) at /build/kvm/git/hw/sysbus.c:133 #3 0x00005555556df670 in qdev_init (dev=0x555556849f60) at /build/kvm/git/hw/qdev.c:293 #4 0x00005555556dfa8a in qdev_init_nofail (dev=0x555556849f60) at /build/kvm/git/hw/qdev.c:387 #5 0x00005555557f9bc2 in ioapic_init (gsi_state=0x55555683ff70) at /build/kvm/git/hw/pc_piix.c:63 #6 0x00005555557f9f76 in pc_init1 (system_memory=0x55555641a1b0, system_io=0x55555641a2b0, ram_size=1073741824, boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at /build/kvm/git/hw/pc_piix.c:166 #7 0x00005555557fa425 in pc_init_pci (ram_size=1073741824, boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0) at /build/kvm/git/hw/pc_piix.c:245 #8 0x00005555556b99ca in main (argc=16, argv=0x7fffffffeb58, envp=0x7fffffffebe0) at /build/kvm/git/vl.c:3351 (gdb) frame 1 #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) at /build/kvm/git/hw/ioapic_common.c:92 92 if (strcmp(b->name, s->backend_name) == 0) { (gdb) p b->name $1 = 0x55555588588d "QEMU" (gdb) p s->backend_name $2 = 0x0 (gdb) _ Thanks! /mjt
On 2011-12-06 20:38, Michael Tokarev wrote: > [Removed some people from the Cc list] > > On 06.12.2011 22:45, Michael Tokarev wrote: > [] >>> git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip >> >> This tree does not boot for me at all (on regular x86-64 setup) - >> it stays in bios after "Booting from hard disk" with 100% CPU >> usage. > > This happens since > > commit 1ae1cec76a205446e6b4e5600ad0af450f7c0b5e > Author: Jan Kiszka <jan.kiszka@siemens.com> > Date: Sun Oct 16 19:38:22 2011 +0200 > > ioapic: Introduce backend/frontend infrastructure for KVM reuse > > Also, with this > > commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7 > Author: Jan Kiszka <jan.kiszka@siemens.com> > Date: Sat Oct 15 11:49:47 2011 +0200 > > kvm: Introduce core services for in-kernel irqchip support > > the whole thing segfaults at startup: > > (gdb) ru -monitor stdio -m 1G -netdev type=tap,ifname=tap-kvm1,script=no,downscript=no,id=n -device rtl8139,netdev=n,mac=52:54:00:12:34:57 -drive file=/stage/win/dist/t.raw,if=ide,cache=unsafe -vga std -usbdevice tablet -enable-kvm > ... > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt > #0 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) > at /build/kvm/git/hw/ioapic_common.c:92 > #2 0x00005555556a0a85 in sysbus_device_init (dev=0x555556849f60, > base=0x555555be7200) at /build/kvm/git/hw/sysbus.c:133 > #3 0x00005555556df670 in qdev_init (dev=0x555556849f60) > at /build/kvm/git/hw/qdev.c:293 > #4 0x00005555556dfa8a in qdev_init_nofail (dev=0x555556849f60) > at /build/kvm/git/hw/qdev.c:387 > #5 0x00005555557f9bc2 in ioapic_init (gsi_state=0x55555683ff70) > at /build/kvm/git/hw/pc_piix.c:63 > #6 0x00005555557f9f76 in pc_init1 (system_memory=0x55555641a1b0, > system_io=0x55555641a2b0, ram_size=1073741824, > boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, > kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0, > pci_enabled=1, kvmclock_enabled=1) at /build/kvm/git/hw/pc_piix.c:166 > #7 0x00005555557fa425 in pc_init_pci (ram_size=1073741824, > boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, > kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0) > at /build/kvm/git/hw/pc_piix.c:245 > #8 0x00005555556b99ca in main (argc=16, argv=0x7fffffffeb58, > envp=0x7fffffffebe0) at /build/kvm/git/vl.c:3351 > (gdb) frame 1 > #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) > at /build/kvm/git/hw/ioapic_common.c:92 > 92 if (strcmp(b->name, s->backend_name) == 0) { > (gdb) p b->name > $1 = 0x55555588588d "QEMU" > (gdb) p s->backend_name > $2 = 0x0 > (gdb) _ > How embarrassing. Messed something up, maybe during rebase, and forgot to retest non-irqchip mode. Will fix and repost. But -machine pc,accel=kvm,kernel_irqchip=on (instead of -enable-kvm) should work. Jan
On 2011-12-06 21:58, Jan Kiszka wrote: > On 2011-12-06 20:38, Michael Tokarev wrote: >> [Removed some people from the Cc list] >> >> On 06.12.2011 22:45, Michael Tokarev wrote: >> [] >>>> git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip >>> >>> This tree does not boot for me at all (on regular x86-64 setup) - >>> it stays in bios after "Booting from hard disk" with 100% CPU >>> usage. >> >> This happens since >> >> commit 1ae1cec76a205446e6b4e5600ad0af450f7c0b5e >> Author: Jan Kiszka <jan.kiszka@siemens.com> >> Date: Sun Oct 16 19:38:22 2011 +0200 >> >> ioapic: Introduce backend/frontend infrastructure for KVM reuse >> >> Also, with this >> >> commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7 >> Author: Jan Kiszka <jan.kiszka@siemens.com> >> Date: Sat Oct 15 11:49:47 2011 +0200 >> >> kvm: Introduce core services for in-kernel irqchip support >> >> the whole thing segfaults at startup: >> >> (gdb) ru -monitor stdio -m 1G -netdev type=tap,ifname=tap-kvm1,script=no,downscript=no,id=n -device rtl8139,netdev=n,mac=52:54:00:12:34:57 -drive file=/stage/win/dist/t.raw,if=ide,cache=unsafe -vga std -usbdevice tablet -enable-kvm >> ... >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >> (gdb) bt >> #0 0x00007ffff5670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) >> at /build/kvm/git/hw/ioapic_common.c:92 >> #2 0x00005555556a0a85 in sysbus_device_init (dev=0x555556849f60, >> base=0x555555be7200) at /build/kvm/git/hw/sysbus.c:133 >> #3 0x00005555556df670 in qdev_init (dev=0x555556849f60) >> at /build/kvm/git/hw/qdev.c:293 >> #4 0x00005555556dfa8a in qdev_init_nofail (dev=0x555556849f60) >> at /build/kvm/git/hw/qdev.c:387 >> #5 0x00005555557f9bc2 in ioapic_init (gsi_state=0x55555683ff70) >> at /build/kvm/git/hw/pc_piix.c:63 >> #6 0x00005555557f9f76 in pc_init1 (system_memory=0x55555641a1b0, >> system_io=0x55555641a2b0, ram_size=1073741824, >> boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, >> kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0, >> pci_enabled=1, kvmclock_enabled=1) at /build/kvm/git/hw/pc_piix.c:166 >> #7 0x00005555557fa425 in pc_init_pci (ram_size=1073741824, >> boot_device=0x7fffffffea30 "cad", kernel_filename=0x0, >> kernel_cmdline=0x55555586fbff "", initrd_filename=0x0, cpu_model=0x0) >> at /build/kvm/git/hw/pc_piix.c:245 >> #8 0x00005555556b99ca in main (argc=16, argv=0x7fffffffeb58, >> envp=0x7fffffffebe0) at /build/kvm/git/vl.c:3351 >> (gdb) frame 1 >> #1 0x00005555557abb3d in ioapic_init (dev=0x555556849f60) >> at /build/kvm/git/hw/ioapic_common.c:92 >> 92 if (strcmp(b->name, s->backend_name) == 0) { >> (gdb) p b->name >> $1 = 0x55555588588d "QEMU" >> (gdb) p s->backend_name >> $2 = 0x0 >> (gdb) _ >> > > How embarrassing. Messed something up, maybe during rebase, and forgot > to retest non-irqchip mode. Will fix and repost. Was even worse, a simple -ENOTTESTED case. Pushed an update at the same location. Thanks, Jan
On 07.12.2011 01:12, Jan Kiszka wrote: > On 2011-12-06 21:58, Jan Kiszka wrote: [] >> How embarrassing. Messed something up, maybe during rebase, and forgot >> to retest non-irqchip mode. Will fix and repost. > > Was even worse, a simple -ENOTTESTED case. Pushed an update at the same > location. Ok, with the updated series everything works correctly. Guests boots, qemu does not segfault at startup anymore, WinXP with StdPC HAL works, even coroutines on mixed 32/64 environment breaks exactly the same way as with qemu-kvm/master ;) Tested both -enable-kvm and -machine pc,accel=kvm,kernel_irqchip=on - both behaves equally (I wasnt' able to spot a difference). What is the "target" syntax -- I assume it is the more verbose one, with -machine, so that -enable-kvm will be dropped at some point, right? Thanks! /mjt
Am 06.12.2011 19:21, schrieb Jan Kiszka: > 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@siemens.com> >>>>> 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@siemens.com> >> 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@siemens.com> >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> >> >> 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?). Justin, I guess (CCed). Not sure if we're planning to have another 0.15.x release, though. Kevin
On 07.12.2011 13:02, Kevin Wolf wrote: > Am 06.12.2011 19:21, schrieb Jan Kiszka: [] >>> 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@siemens.com> >>> 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@siemens.com> >>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> >>> >>> 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?). > > Justin, I guess (CCed). Not sure if we're planning to have another > 0.15.x release, though. Note that I haven't actually tested this commit alone on top of 0.15. But I already commented on this - there's no good reason - imho anyway - to fix that for 0.15. I'll try to push 1.0 to debian asap (waiting for libvirt to catch up) to close this issue there, other distros should hurry up too ;) Thanks! /mjt
diff --git a/hw/piix_pci.c b/hw/piix_pci.c index ee11ff2..5b35c01 100644 --- a/hw/piix_pci.c +++ b/hw/piix_pci.c @@ -38,28 +38,12 @@ typedef PCIHostState I440FXState; -#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */ #define PIIX_NUM_PIRQS 4ULL /* PIRQ[A-D] */ #define XEN_PIIX_NUM_PIRQS 128ULL #define PIIX_PIRQC 0x60 typedef struct PIIX3State { PCIDevice dev; - - /* - * bitmap to track pic levels. - * The pic level is the logical OR of all the PCI irqs mapped to it - * So one PIC level is tracked by PIIX_NUM_PIRQS bits. - * - * PIRQ is mapped to PIC pins, we track it by - * PIIX_NUM_PIRQS * PIIX_NUM_PIC_IRQS = 64 bits with - * pic_irq * PIIX_NUM_PIRQS + pirq - */ -#if PIIX_NUM_PIC_IRQS * PIIX_NUM_PIRQS > 64 -#error "unable to encode pic state in 64bit in pic_levels." -#endif - uint64_t pic_levels; - qemu_irq *pic; /* This member isn't used. Just for save/load compatibility */ @@ -365,61 +349,24 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn, return b; } -/* PIIX3 PCI to ISA bridge */ -static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq) -{ - qemu_set_irq(piix3->pic[pic_irq], - !!(piix3->pic_levels & - (((1ULL << PIIX_NUM_PIRQS) - 1) << - (pic_irq * PIIX_NUM_PIRQS)))); -} - -static void piix3_set_irq_level(PIIX3State *piix3, int pirq, int level) -{ - int pic_irq; - uint64_t mask; - - pic_irq = piix3->dev.config[PIIX_PIRQC + pirq]; - if (pic_irq >= PIIX_NUM_PIC_IRQS) { - return; - } - - mask = 1ULL << ((pic_irq * PIIX_NUM_PIRQS) + pirq); - piix3->pic_levels &= ~mask; - piix3->pic_levels |= mask * !!level; - - piix3_set_irq_pic(piix3, pic_irq); -} - -static void piix3_set_irq(void *opaque, int pirq, int level) +static void piix3_set_irq(void *opaque, int irq_num, int level) { + int i, pic_irq, pic_level; PIIX3State *piix3 = opaque; - piix3_set_irq_level(piix3, pirq, level); -} - -/* irq routing is changed. so rebuild bitmap */ -static void piix3_update_irq_levels(PIIX3State *piix3) -{ - int pirq; - - piix3->pic_levels = 0; - for (pirq = 0; pirq < PIIX_NUM_PIRQS; pirq++) { - piix3_set_irq_level(piix3, pirq, - pci_bus_get_irq_level(piix3->dev.bus, pirq)); - } -} -static void piix3_write_config(PCIDevice *dev, - uint32_t address, uint32_t val, int len) -{ - pci_default_write_config(dev, address, val, len); - if (ranges_overlap(address, len, PIIX_PIRQC, 4)) { - PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev); - int pic_irq; - piix3_update_irq_levels(piix3); - for (pic_irq = 0; pic_irq < PIIX_NUM_PIC_IRQS; pic_irq++) { - piix3_set_irq_pic(piix3, pic_irq); + /* now we change the pic irq level according to the piix irq mappings */ + /* XXX: optimize */ + pic_irq = piix3->dev.config[0x60 + irq_num]; + if (pic_irq < 16) { + /* The pic level is the logical OR of all the PCI irqs mapped + to it */ + pic_level = 0; + for (i = 0; i < 4; i++) { + if (pic_irq == piix3->dev.config[0x60 + i]) { + pic_level |= pci_bus_get_irq_level(piix3->dev.bus, i); + } } + qemu_set_irq(piix3->pic[pic_irq], pic_level); } } @@ -434,7 +381,7 @@ static void piix3_write_config_xen(PCIDevice *dev, uint32_t address, uint32_t val, int len) { xen_piix_pci_write_config_client(address, val, len); - piix3_write_config(dev, address, val, len); + pci_default_write_config(dev, address, val, len); } static void piix3_reset(void *opaque) @@ -473,15 +420,6 @@ static void piix3_reset(void *opaque) pci_conf[0xab] = 0x00; pci_conf[0xac] = 0x00; pci_conf[0xae] = 0x00; - - d->pic_levels = 0; -} - -static int piix3_post_load(void *opaque, int version_id) -{ - PIIX3State *piix3 = opaque; - piix3_update_irq_levels(piix3); - return 0; } static void piix3_pre_save(void *opaque) @@ -500,7 +438,6 @@ static const VMStateDescription vmstate_piix3 = { .version_id = 3, .minimum_version_id = 2, .minimum_version_id_old = 2, - .post_load = piix3_post_load, .pre_save = piix3_pre_save, .fields = (VMStateField []) { VMSTATE_PCI_DEVICE(dev, PIIX3State), @@ -541,7 +478,6 @@ static PCIDeviceInfo i440fx_info[] = { .qdev.no_user = 1, .no_hotplug = 1, .init = piix3_initfn, - .config_write = piix3_write_config, .vendor_id = PCI_VENDOR_ID_INTEL, .device_id = PCI_DEVICE_ID_INTEL_82371SB_0, // 82371SB PIIX3 PCI-to-ISA bridge (Step A1) .class_id = PCI_CLASS_BRIDGE_ISA,