winXP "Standard PC" HAL and qemu-kvm >= 0.15

winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

As it turned out, a windowsXP machine does not work in
qemu-kvm >= 0.15 (it loses network and USB entirely)
if it is using "Standard PC" HAL.  In 0.14 it worked
fine, but not in 0.14 (I haven't tried any in-between
versions yet).

There are several HAL types available in winXP: these
are "Uniprocessor PC with MPS" (or Multiprocessor),
also two ACPI types, and "Standard PC".  All the other
HAL types appears to work fine, but not "Standard PC".

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.

So, if anybody have some thoughts about this issue,
and especially if you know a way to switch winXP HAL
type to some ACPI variant without reinstalling, please
speak up.. ;)

Debian bugreport for a reference: http://bugs.debian.org/647312

Reproducer: install a winXP guest on kvm with -no-acpi so
it chooses an "Uniprocessor with MPS" HAL.  Switch it to
"Standard PC" in device manager, reboot -- in 0.15+ it does
not work anymore, while in 0.14 it continues to work fine.

Thank you!

/mjt

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Avi Kivity]

On 12/05/2011 11:21 AM, Michael Tokarev wrote:
> As it turned out, a windowsXP machine does not work in
> qemu-kvm >= 0.15 (it loses network and USB entirely)
> if it is using "Standard PC" HAL.  In 0.14 it worked
> fine, but not in 0.14 (I haven't tried any in-between
> versions yet).
>
> There are several HAL types available in winXP: these
> are "Uniprocessor PC with MPS" (or Multiprocessor),
> also two ACPI types, and "Standard PC".  All the other
> HAL types appears to work fine, but not "Standard PC".
>
> 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.

> So, if anybody have some thoughts about this issue,
> and especially if you know a way to switch winXP HAL
> type to some ACPI variant without reinstalling, please
> speak up.. ;)

I remember doing it somewhere in device manager, perhaps in the
processor entry.  But it was years since I last did this.

> Debian bugreport for a reference: http://bugs.debian.org/647312
>
> Reproducer: install a winXP guest on kvm with -no-acpi so
> it chooses an "Uniprocessor with MPS" HAL.  Switch it to
> "Standard PC" in device manager, reboot -- in 0.15+ it does
> not work anymore, while in 0.14 it continues to work fine.

Most likely non-ACPI interrupt routing.

-- 
error compiling committee.c: too many arguments to function

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

On 05.12.2011 17:28, Avi Kivity wrote:
[]
>> 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.

So today I gave it a chance with git bisect, and here's what it found:

First bad commit ef390067a72fe09977bb4ac8211313e1503302ea
Merge: c7b3e90 0fd542f
Author: Avi Kivity <avi@redhat.com>
Date:   Sun May 15 04:48:05 2011 -0400

    Merge commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df' into upstream-merge

    * commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df':
      cpu: add set_memory flag to request dirty logging
      piix_pci: load path clean up
      piix_pci: optimize set irq path
      piix_pci: eliminate PIIX3State::pci_irq_levels
      pci: add accessor function to get irq levels
      cirrus_vga: remove unneeded reset

    Conflicts:
        exec.c

    Signed-off-by: Avi Kivity <avi@redhat.com>

And just like with the 32/64bit lockup issue, this is a merge
commit, which is not exactly useful.

Any guesses? :)

The problem is that so far, there's no known way to change to
use proper hal type in winXP (except of reinstalling the guest),
and there's no known workaround on the kvm side, so users are
stuck with older versions.

>> So, if anybody have some thoughts about this issue,
>> and especially if you know a way to switch winXP HAL
>> type to some ACPI variant without reinstalling, please
>> speak up.. ;)
> 
> I remember doing it somewhere in device manager, perhaps in the
> processor entry.  But it was years since I last did this.

As I already mentioned, changing HAL type works from anything to
"Standard PC", but not back.  I'll try to investigate.

>> Debian bugreport for a reference: http://bugs.debian.org/647312
>>
>> Reproducer: install a winXP guest on kvm with -no-acpi so
>> it chooses an "Uniprocessor with MPS" HAL.  Switch it to
>> "Standard PC" in device manager, reboot -- in 0.15+ it does
>> not work anymore, while in 0.14 it continues to work fine.
> 
> Most likely non-ACPI interrupt routing.

The commit it bisected to talks about piix -- may it be related?

Thanks,

/mjt

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Avi Kivity]

On 12/05/2011 10:19 PM, Michael Tokarev wrote:
> On 05.12.2011 17:28, Avi Kivity wrote:
> []
> >> 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.
>
> So today I gave it a chance with git bisect, and here's what it found:
>
> First bad commit ef390067a72fe09977bb4ac8211313e1503302ea
> Merge: c7b3e90 0fd542f
> Author: Avi Kivity <avi@redhat.com>
> Date:   Sun May 15 04:48:05 2011 -0400
>
>     Merge commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df' into upstream-merge
>
>     * commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df':
>       cpu: add set_memory flag to request dirty logging
>       piix_pci: load path clean up
>       piix_pci: optimize set irq path
>       piix_pci: eliminate PIIX3State::pci_irq_levels
>       pci: add accessor function to get irq levels
>       cirrus_vga: remove unneeded reset
>
>     Conflicts:
>         exec.c
>
>     Signed-off-by: Avi Kivity <avi@redhat.com>
>
> And just like with the 32/64bit lockup issue, this is a merge
> commit, which is not exactly useful.

It's possible to bisect this fully, though it isn't trivial:

 - if bisect gives you a qemu-kvm commit (usually easy to tell from the
context, but you can tell for sure by looking at whether 'git rev-list
HEAD^.. ^upstream' gives you anything, where 'upstream' points to
qemu.git), just test it
- otherwise, find out which qemu-kvm commit merged HEAD:

  - issue 'git name-rev --ref=refs/heads/master HEAD', where
refs/heads/master is qemu-kvm's master branch (likely
refs/remotes/qemu-kvm/master for you).
  - you get something like "master~9^2~40"
  - take off the rightmost '^' and everything that follows it.  See if
it's a qemu-kvm commit.  If not, take off another rightmost ^ and repeat.
  - call the result M.

- if HEAD is the last commit merged by M ('git rev-parse M^2' is
identical to 'git rev-parse HEAD'), then just merge M.
- otherwise, merge M^.
- test the result, and feed it back to 'git bisect'

it's pretty laborious to do this.  I guess we should script it.


In your case, we already know M.  So you could do

$ git bisect start M M^
(git spits out a commit)
$ git merge --no-commit M^
(build & test)
$ git checkout -f
$ git bisect [good|bad]
(repeat)

> Any guesses? :)
>
> The problem is that so far, there's no known way to change to
> use proper hal type in winXP (except of reinstalling the guest),

I'd much rather fix the bug than find workarounds.

> and there's no known workaround on the kvm side, so users are
> stuck with older versions.
>
> >> So, if anybody have some thoughts about this issue,
> >> and especially if you know a way to switch winXP HAL
> >> type to some ACPI variant without reinstalling, please
> >> speak up.. ;)
> > 
> > I remember doing it somewhere in device manager, perhaps in the
> > processor entry.  But it was years since I last did this.
>
> As I already mentioned, changing HAL type works from anything to
> "Standard PC", but not back.  I'll try to investigate.
>
> >> Debian bugreport for a reference: http://bugs.debian.org/647312
> >>
> >> Reproducer: install a winXP guest on kvm with -no-acpi so
> >> it chooses an "Uniprocessor with MPS" HAL.  Switch it to
> >> "Standard PC" in device manager, reboot -- in 0.15+ it does
> >> not work anymore, while in 0.14 it continues to work fine.
> > 
> > Most likely non-ACPI interrupt routing.
>
> The commit it bisected to talks about piix -- may it be related?

Very likely.  Please try the shorter bisect procedure above.

-- 
error compiling committee.c: too many arguments to function

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

On 06.12.2011 14:32, Avi Kivity wrote:
> On 12/05/2011 10:19 PM, Michael Tokarev wrote:
>> On 05.12.2011 17:28, Avi Kivity wrote:
>> []
>>>> 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.
>>
>> So today I gave it a chance with git bisect, and here's what it found:

>> First bad commit ef390067a72fe09977bb4ac8211313e1503302ea
>> Merge: c7b3e90 0fd542f
>> Author: Avi Kivity <avi@redhat.com>
>> 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
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

    optimize irq routing in piix_pic.c which has been a TODO.
    So far piix3 tracks each pirq level and checks whether a given pic pins is
    asserted by seeing if each pirq is mapped into the pic pin.
    This is independent on irq routing, but data path is on slow path.

    Given that irq routing is rarely changed and asserting pic pins is on
    data path, the path that asserts pic pins should be optimized and
    chainging irq routing should be on slow path.
    The new behavior with this patch series is to use bitmap which is addressed
    by pirq and pic pins with a given irq routing.
    When pirq is asserted, the bitmap is set and see if the pic pins is
    asserted by checking the bitmaps.
    When irq routing is changed, rebuild the bitmap and re-assert pic pins.

    test:
    - create VM with 4 e1000 nics in different pci slots
      (i.e. fn=0 for each e1000)
      Thus those e1000's INTA are connected to each PIRQ[A-D].
    - run linux as guest and saw each devices triggers interrupt
      by seeing /proc/interrupts. And then confirmed that each PIRQ[A-D]
      surely asserted interrupts.
      Because irq 10 and 11 are shared by 4 e1000's, it only one NIC is activated
      with ifconfig ethN up/down when counting interrupts.

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

So I'm Cc'ing the relevant people for this.
For ones who didn't see the original problem, here's the thread:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705/focus=82851

Thanks!

/mjt

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael S. Tsirkin]

On Tue, Dec 06, 2011 at 03:02:49PM +0400, Michael Tokarev wrote:
> On 06.12.2011 14:32, Avi Kivity wrote:
> > On 12/05/2011 10:19 PM, Michael Tokarev wrote:
> >> On 05.12.2011 17:28, Avi Kivity wrote:
> >> []
> >>>> 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.
> >>
> >> So today I gave it a chance with git bisect, and here's what it found:
> 
> >> First bad commit ef390067a72fe09977bb4ac8211313e1503302ea
> >> Merge: c7b3e90 0fd542f
> >> Author: Avi Kivity <avi@redhat.com>
> >> 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
> 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.

commit 8f40db3918a0618a3beb9a771a569d20fe9c1bb3
Author: Michael S. Tsirkin <mst@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,

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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

Re: [Qemu-devel] winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

[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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Jan Kiszka]

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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Jan Kiszka]

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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[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?).

> 
>> 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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

[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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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

Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Kevin Wolf]

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

Re: [Qemu-devel] winXP "Standard PC" HAL and qemu-kvm >= 0.15

[Michael Tokarev]

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