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

[Avi Kivity <avi@redhat.com>]

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