Bug 520284 - KQEMU support not compiled after F11 QEMU-KVM merge
KQEMU support not compiled after F11 QEMU-KVM merge
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-30 02:53 EDT by Cong Ma
Modified: 2009-10-22 21:33 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-31 23:39:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
enables kqemu in non-KVM builds (kqemu not included) (315 bytes, patch)
2009-10-19 18:05 EDT, Tony Nelson
no flags Details | Diff
How to change the qemu specfile to allow the previous kqemu patch (1.25 KB, application/octet-stream)
2009-10-19 18:10 EDT, Tony Nelson
no flags Details

  None (edit)
Description Cong Ma 2009-08-30 02:53:40 EDT
Description of problem:

The QEMU accelerator feature is no longer compiled in the QEMU packages. The command line options "-kernel-kqemu" or "-no-kqemu" are not recognized by F11's qemu command, and the feature cannot be enabled.

On older x86 chips without KVM support, the KQEMU accelerator provides a significant boost in performance for Linux guests. Although the KQEMU kernel module itself is in RPMFusion, it cannot be utilized by F11's qemu program without some compile-time configuration.


Version-Release number of selected component (if applicable):

qemu-system-x86-0.10.6-1.fc11.i586


Additional info:

I took a look at the Koji build log. Although there was no explicit flag "-disable-kqemu" passed to the configure script, the new build process tailored for KVM didn't seem compatible with the KQEMU support feature. In the configure output it was reported that KQEMU was not enabled.

According to Fedora 11's Release Notes (http://docs.fedoraproject.org/release-notes/f11/en-US/sect-Release_Notes-Virtualization.html#sect-Release_Notes-Other_Improvements-QEMU_Updated_to_0.10.0), KQEMU should have been supported as usual, unaffected by the KVM merge. I believe this must also be the intended result in the mind of Fedora developers. The wiki also said "No user visible change is expected. Users should be able to run guests in the very same way they did before." (https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge#User_Experience)

I hope you could look into this issue. Thank you.
Comment 1 Glauber Costa 2009-08-31 07:02:00 EDT
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.
Comment 2 Cong Ma 2009-08-31 23:39:55 EDT
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.
Comment 3 Tony Nelson 2009-10-19 18:02:01 EDT
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.
Comment 4 Tony Nelson 2009-10-19 18:05:28 EDT
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.
Comment 5 Tony Nelson 2009-10-19 18:10:39 EDT
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.
Comment 6 Athmane Madjoudj 2009-10-20 11:43:06 EDT
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.
Comment 7 Daniel Berrange 2009-10-20 11:50:28 EDT
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
Comment 8 Tony Nelson 2009-10-20 14:18:54 EDT
(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.
Comment 9 Glauber Costa 2009-10-20 14:27:13 EDT
(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.
Comment 10 Tony Nelson 2009-10-20 18:25:01 EDT
(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.
Comment 11 Glauber Costa 2009-10-21 07:52:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.