From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gordan Bobic <gordan@bobich.net>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Date: Fri, 05 Feb 2010 13:14:58 +0100 [thread overview]
Message-ID: <4B6C0BC2.1000508@siemens.com> (raw)
In-Reply-To: <4B6B9794.3040507@bobich.net>
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. That was one of the reasons why
no one worked on it anymore and, thus, it is no longer supported by QEMU
starting with release 0.12.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2010-02-05 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-05 3:59 [Qemu-devel] kqemu and XP guest - lock-up at mup.sys Gordan Bobic
2010-02-05 12:14 ` Jan Kiszka [this message]
2010-02-05 13:34 ` [Qemu-devel] " Gordan Bobic
2010-02-05 16:13 ` Jamie Lokier
2010-02-05 16:58 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B6C0BC2.1000508@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=gordan@bobich.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).