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

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

[Gordan Bobic]

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?

Thanks.

Gordan

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

[Jan Kiszka]

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

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

[Gordan Bobic]

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

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

[Jamie Lokier]

Gordan Bobic wrote:
> Jan Kiszka wrote:
> >Gordan Bobic wrote:
> >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.

No, it isn't.  The VT/SVM extensions used by KVM support much more
accurate virtualisation than the tricks used by kqemu.  There are a
few bugs and omissions in KVM itself, but for most things it's a high
quality virtualisation.

-- Jamie

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

[Jan Kiszka]

Gordan Bobic wrote:
> 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.

As Jamie already pointed out, your perception of KVM is not correct. But
the issue of legacy hardware exists, no question. Just the effort to
keep it working is beyond reasonable limits.

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

The differences are various and subtle. If you want to understand them
(you do not, believe me), look at the code of kqemu or even debug it -
under KVM like we did. But, again, you do not want to do this...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux