Bug 520284

Hello.

The discussion involving kqemu is quite extensive. Basically, it is an unmaintanable piece of software that nobody in the community really understand, and places a severe burden on other technologies.

As an example, the mere fact that we compile kqemu (we don't even have to use it), restricts guest memory usage to 4Gb, which is unacceptable. And this is by design, not by accident.

We decided to remove it earlier for the benefit of KVM, which is a newer and more mature technology, but it is by no means different than any other flag you could disable (if we compiled qemu with any --disable flag, you wouldn't be able to use it too)

Please note that, while kqemu is present at the 0.10 series, and theoretically I could even provide you with a package that has it enabled, it is compiled-out-by-default in 0.11, and definitely removed in 0.12. Although earlier, Fedora is not taking any actions that go against upstream directions. Unfortunately for its users, kqemu removal was always a matter of time. Inevitable.

Please scan qemu-devel archives for more details on that.

Hi,

Thank you for your explanation. I think I can close this bug now. I'll try compiling my own QEMU with kqemu support and install it in parallel with the Fedora package.

For those without a machine that can run KVM, kqemu is needed to get the last factor of 5 of emulator speed.  Although KVM and kqemu are not compatible, kqemu is compatible with the non-KVM build of the x86 emulator.  If simply enabling the use of kqemu does restrict the resulting emulator to 4 GiB, then two x86 emulator packages should be built, with and without kqemu support.  Note that kqemu is packaged by RPM-Fusion, and it would be a shame for them to have to also package qemu just to make their kqemu usable.

Created attachment 365285 [details]
enables kqemu in non-KVM builds (kqemu not included)

This patch and the following specfile patch re-enable kqemu in qemu x86 builds, though not in KVM builds.  Kqemu is not included, but is available at RPMFusion.

Created attachment 365286 [details]
How to change the qemu specfile to allow the previous kqemu patch

Just in case someone other than the packabe maintainer needs to work around kqemu being disabled (in order to use the kqemu package from RPMFusion), here is what to do.  Please use your own initials in the package Release field; don't just apply this as a patch.

Hello all,

By enabling kqemu you'll spread qemu (and the wonderful virt-manager) for those who doesn't own a virtualization capable CPU, and offer something free (libre) and open source alternative.

Thanks so much.

FYI, no matter what comments you might add to this bug,  kqemu is not going to reappear.

 - It depends on a kernel module that was never accepted in upstream LKML
 - All kqemu support & code has been removed by upstream QEMU developers
 - kqemu support imposes unacceptable restrictions on non-kqemu functionality
    ie cripples the i386 QEMU/KVM modes to a memory limit of < 2 GB

(In reply to comment #7)
> FYI, no matter what comments you might add to this bug,  kqemu is not going to
> reappear.

kqemu reappears whenever someone applies the patches I uploaded, whether Fedora ships it or not.  FYI.

>  - It depends on a kernel module that was never accepted in upstream LKML

Not relevent to Fedora, see recent threads on the -devel list.  Several Fedora packages depend on kernel modules or other software that will never be accepted into the kernel or Fedora.  Kqemu is available from RPM-Fusion.

>  - All kqemu support & code has been removed by upstream QEMU developers

False, unless the qemu package in Fedora is a significant fork of upstream QEMU.  Really now, did you even look at the patch?  How could so few lines re-introduce kqemu after its removal by the QEMU developers?

>  - kqemu support imposes unacceptable restrictions on non-kqemu functionality
>     ie cripples the i386 QEMU/KVM modes to a memory limit of < 2 GB  

Or perhaps KVM support imposes unacceptable restrictions on normal QEMU, ie cripples the i386 QEMU non-KVM mode to very slow performance?  You are being silly.  All that is needed is a separate subpackage for x86-kqemu with kqemu not disabled, just like the subpackage for KVM support.  It would only be a few lines in the spec file, just like the KVM subpackage.  Look at the patch.

(In reply to comment #8)
> (In reply to comment #7)
> > FYI, no matter what comments you might add to this bug,  kqemu is not going to
> > reappear.
> 
> kqemu reappears whenever someone applies the patches I uploaded, whether Fedora
> ships it or not.  FYI.
For a while. Since it is *completely* removed in qemu-0.12, what would you plan to do afterwards?

> 
> >  - All kqemu support & code has been removed by upstream QEMU developers
> 
> False, unless the qemu package in Fedora is a significant fork of upstream
> QEMU.  Really now, did you even look at the patch?  How could so few lines
> re-introduce kqemu after its removal by the QEMU developers?
Not False. True. You probably don't follow qemu-devel. The rpm we ship with fedora11 still have some kqemu code. But it is now removed upstream. This is the biggest "We can't sanely support it!" statement that can ever be.

> 
> >  - kqemu support imposes unacceptable restrictions on non-kqemu functionality
> >     ie cripples the i386 QEMU/KVM modes to a memory limit of < 2 GB  
> 
> Or perhaps KVM support imposes unacceptable restrictions on normal QEMU, ie
> cripples the i386 QEMU non-KVM mode to very slow performance?  You are being
> silly.  All that is needed is a separate subpackage for x86-kqemu with kqemu
> not disabled, just like the subpackage for KVM support.  It would only be a few
> lines in the spec file, just like the KVM subpackage.  Look at the patch.  

Again, even in the event of us applying it here, all you would get is a few extra months. kqemu is a terminal patient, and already dead upstream.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > FYI, no matter what comments you might add to this bug,  kqemu is
> > > not going to reappear.
> > 
> > kqemu reappears whenever someone applies the patches I uploaded,
> > whether Fedora ships it or not.  FYI.
> For a while. Since it is *completely* removed in qemu-0.12, what would
> you plan to do afterwards?
 ...

What everyone who needs a useful QEMU on their present hardware will do:  stay with a working version or switch to a competing project, either VMWare or VirtualBox.  QEMU can go its own way, if it will no longer be useful as an emulator on x86.  Don't blame the users when FOSS gives up on them.

As far as it might (In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > FYI, no matter what comments you might add to this bug,  kqemu is
> > > > not going to reappear.
> > > 
> > > kqemu reappears whenever someone applies the patches I uploaded,
> > > whether Fedora ships it or not.  FYI.
> > For a while. Since it is *completely* removed in qemu-0.12, what would
> > you plan to do afterwards?
>  ...
> 
> What everyone who needs a useful QEMU on their present hardware will do:  stay
> with a working version or switch to a competing project, either VMWare or
> VirtualBox.  QEMU can go its own way, if it will no longer be useful as an
> emulator on x86.  Don't blame the users when FOSS gives up on them.  

As fair as it might be, this is a discussion that belongs upstream, not here.