qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys


From: Gordan Bobic
Subject: Re: [Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Date: Fri, 05 Feb 2010 13:34:24 +0000
User-agent: Thunderbird 2.0.0.22 (X11/20090625)

Jan Kiszka wrote:
Gordan Bobic wrote:
Hi,

It would appear that kqemu somehow breaks the XP guest under some
circumstances.

If I install from scratch in qemu+kqemu, it works fine in kqemu, but not
on bare metal. The fact it doesn't work on bare metal COULD be related
to the fact that on bare metal I'm running off a USB stick (it's a
rescue system).

If I install onto bare metal (again, onto a USB stick - I have a
modified installer that includes the USB disk drivers at setup stage)
and then start up that install in qemu, that works as long as I don't
apply kqemu. But if I modprobe kqemu and start with
-enable-kqemu/-kernel-kqemu (-smp 1 in all cases), the quest instanty
locks up at 100% CPU usage. Everything else about the qemu configuration
is exactly the same between the runs. Booting the system with -no-acpi
at this point causes it to reboot instead of just locking up.

I tried with qemu 0.10.5 (RHEL5 from atrpms) and 0.11.1 (built from
source). kqemu I use is dkms 1.4.0pre1 from the Dag repository.

With kqemu, the guest stops booting (including safe mode) at mup.sys.
Googling around for similar problems didn't reveal much of use (other
than the usual Windows solution to everything of "reinstall", which
isn't an option here because I need the same setup to work both on bare
metal and in qemu). Is there a work-around/tweak to make this work? Is
there any particular reason why kqemu would break things under these
circumstances when running without kqemu works fine, if slower? Is there
a difference in how the emulated hardware looks/behaves with and without
kqemu?

Due to limitations of the x86 architecture, kqemu used to be far a way
from providing accurate virtualization.

KVM is subject to the same limitations, though, so that point is a bit moot. The only reason why I'm using kqemu is because I still have legacy 32-bit hardware around that doesn't have VT extensions.

Either way, I'm mainly interested in the details of the differences in the environment provided by qemu with and without kqemu, as clearly it is this difference that causes the problem in question.

Gordan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]