Discussion:
winXP "Standard PC" HAL and qemu-kvm >= 0.15
(too old to reply)
Michael S. Tsirkin
2011-12-06 12:27:53 UTC
Permalink
[]
I haven't debugged further yet, -- because it were
not easy to find out what was causing the regression
and how to reproduce it, and also because I don't think
it is the right HAL for qemu-kvm guest anyway.
It's not, but the regression indicates we broke something. It would be
good to know what that is.
First bad commit ef390067a72fe09977bb4ac8211313e1503302ea
Merge: c7b3e90 0fd542f
Date: Sun May 15 04:48:05 2011 -0400
Merge commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df' into upstream-merge
And after applying Avi's instructions here's the real bisect
ab431c283e7055bcd6fb622f212bb29e84a6a134 is the first bad commit
commit ab431c283e7055bcd6fb622f212bb29e84a6a134
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.

commit 8f40db3918a0618a3beb9a771a569d20fe9c1bb3
Author: Michael S. Tsirkin <***@redhat.com>
Date: Tue Dec 6 14:24:32 2011 +0200

Revert "piix_pci: optimize set irq path"

This reverts commit ab431c283e7055bcd6fb622f212bb29e84a6a134.

Conflicts:

hw/piix_pci.c

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,
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Tokarev
2011-12-06 14:45:52 UTC
Permalink
[]
Post by Michael S. Tsirkin
And after applying Avi's instructions here's the real bisect
ab431c283e7055bcd6fb622f212bb29e84a6a134 is the first bad commit
commit ab431c283e7055bcd6fb622f212bb29e84a6a134
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Tokarev
2011-12-06 16:29:31 UTC
Permalink
[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]
Post by Michael Tokarev
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 <***@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 <***@siemens.com>
Signed-off-by: Avi Kivity <***@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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Kiszka
2011-12-06 16:38:35 UTC
Permalink
Post by Michael Tokarev
[Added Jan Kiszka to Cc]
[complete thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705]
Post by Michael Tokarev
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
commit 59539c913383fdd3350681301b44f02fa7ee2757
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.
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
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Michael Tokarev
2011-12-06 16:57:46 UTC
Permalink
[]
Post by Jan Kiszka
Post by Michael Tokarev
It appears there are two issues here, one is fixed by
09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
Or 3... :)
Post by Jan Kiszka
Post by Michael Tokarev
commit 59539c913383fdd3350681301b44f02fa7ee2757
Date: Mon Jun 27 12:22:28 2011 +0200
qemu-kvm: Fix in-kernel PIC reset
[]
Post by Jan Kiszka
Post by Michael Tokarev
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.
Post by Jan Kiszka
[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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Kiszka
2011-12-06 17:45:07 UTC
Permalink
Post by Michael Tokarev
[]
Post by Jan Kiszka
Post by Michael Tokarev
It appears there are two issues here, one is fixed by
09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
Or 3... :)
Post by Jan Kiszka
Post by Michael Tokarev
commit 59539c913383fdd3350681301b44f02fa7ee2757
Date: Mon Jun 27 12:22:28 2011 +0200
qemu-kvm: Fix in-kernel PIC reset
[]
Post by Jan Kiszka
Post by Michael Tokarev
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.
Post by Michael Tokarev
Post by Jan Kiszka
[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
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Michael Tokarev
2011-12-06 18:13:18 UTC
Permalink
Post by Michael Tokarev
[]
Post by Jan Kiszka
Post by Michael Tokarev
It appears there are two issues here, one is fixed by
09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
Or 3... :)
Post by Jan Kiszka
Post by Michael Tokarev
commit 59539c913383fdd3350681301b44f02fa7ee2757
Date: Mon Jun 27 12:22:28 2011 +0200
qemu-kvm: Fix in-kernel PIC reset
[]
Post by Jan Kiszka
Post by Michael Tokarev
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 <***@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 <***@siemens.com>
Signed-off-by: Blue Swirl <***@gmail.com>

Which is quite expected having in mind the commit which "broke"
it for 0.15.
Post by Michael Tokarev
Upstream qemu 1.0 does not have this issue too.
Post by Jan Kiszka
[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
Jan Kiszka
2011-12-06 18:21:30 UTC
Permalink
Post by Michael Tokarev
Post by Michael Tokarev
[]
Post by Jan Kiszka
Post by Michael Tokarev
It appears there are two issues here, one is fixed by
09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
Or 3... :)
Post by Jan Kiszka
Post by Michael Tokarev
commit 59539c913383fdd3350681301b44f02fa7ee2757
Date: Mon Jun 27 12:22:28 2011 +0200
qemu-kvm: Fix in-kernel PIC reset
[]
Post by Jan Kiszka
Post by Michael Tokarev
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
commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8
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.
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?).
Post by Michael Tokarev
Post by Michael Tokarev
Upstream qemu 1.0 does not have this issue too.
Post by Jan Kiszka
[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
Michael Tokarev
2011-12-06 18:45:26 UTC
Permalink
On 06.12.2011 22:21, Jan Kiszka wrote:
[]
Post by Jan Kiszka
Post by Michael Tokarev
For the 0.15 .. 1.0 change, the first commit which restores the (broken
commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8
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.
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.
Post by Jan Kiszka
Post by Michael Tokarev
Post by Michael Tokarev
Upstream qemu 1.0 does not have this issue too.
Post by Jan Kiszka
[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
Michael Tokarev
2011-12-06 19:38:25 UTC
Permalink
[Removed some people from the Cc list]

On 06.12.2011 22:45, Michael Tokarev wrote:
[]
Post by Michael Tokarev
Post by Jan Kiszka
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 <***@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 <***@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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Kiszka
2011-12-06 20:58:49 UTC
Permalink
Post by Michael Tokarev
[Removed some people from the Cc list]
[]
Post by Michael Tokarev
Post by Jan Kiszka
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
Date: Sun Oct 16 19:38:22 2011 +0200
ioapic: Introduce backend/frontend infrastructure for KVM reuse
Also, with this
commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7
Date: Sat Oct 15 11:49:47 2011 +0200
kvm: Introduce core services for in-kernel irqchip support
(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
Jan Kiszka
2011-12-06 21:12:43 UTC
Permalink
Post by Jan Kiszka
Post by Michael Tokarev
[Removed some people from the Cc list]
[]
Post by Michael Tokarev
Post by Jan Kiszka
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
Date: Sun Oct 16 19:38:22 2011 +0200
ioapic: Introduce backend/frontend infrastructure for KVM reuse
Also, with this
commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7
Date: Sat Oct 15 11:49:47 2011 +0200
kvm: Introduce core services for in-kernel irqchip support
(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
Michael Tokarev
2011-12-07 07:11:20 UTC
Permalink
[]
Post by Jan Kiszka
Post by Jan Kiszka
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin Wolf
2011-12-07 09:02:56 UTC
Permalink
Post by Jan Kiszka
Post by Michael Tokarev
Post by Michael Tokarev
[]
Post by Jan Kiszka
Post by Michael Tokarev
It appears there are two issues here, one is fixed by
09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and
Or 3... :)
Post by Jan Kiszka
Post by Michael Tokarev
commit 59539c913383fdd3350681301b44f02fa7ee2757
Date: Mon Jun 27 12:22:28 2011 +0200
qemu-kvm: Fix in-kernel PIC reset
[]
Post by Jan Kiszka
Post by Michael Tokarev
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
commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8
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.
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
Michael Tokarev
2011-12-07 09:31:51 UTC
Permalink
[]
Post by Kevin Wolf
Post by Jan Kiszka
Post by Michael Tokarev
For the 0.15 .. 1.0 change, the first commit which restores the (broken
commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8
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.
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Continue reading on narkive:
Loading...