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

[Michael Tokarev <mjt@tls.msk.ru>]

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