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