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@xxxxxxxxxx>
> 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@xxxxxxxxxx>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
