<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>On 03.02.2012 15:19, Robby Workman wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>On Fri, 3 Feb 2012 22:55:49 +0100
Matteo Bernardini <<a href="mailto:matteo.bernardini@gmail.com">matteo.bernardini@gmail.com</a>> wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">2012/2/3 Robby Workman <<a href="mailto:rworkman@slackbuilds.org">rworkman@slackbuilds.org</a>>:
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">Yes, similar to that is what aqemu does.  It looks for both "kvm" and "qemu-kvm" binaries, hence my suggestion of linking it to "qemu-kvm" in the script.  Perhaps both is better...</blockquote>
I was missing that libvirt looks also for qemu-kvm, in this case for me qemu-kvm is ok as well :)</blockquote>
<pre>Okay, then the proposal is to only rename the binary.  
Stu, still following this?  :)</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">Oh, I see.  Good point.  In other words, you don't want to have to install the regular "qemu" package to get the keymaps and such, as all you care about are x86* architectures.</blockquote>
Nono, I am about to use it extensively with ARM ones :)</blockquote>
<pre>But ARM doesn't make use of KVM extensions, and that leads to...</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">It's just that I think that usually, between qemu-kvm and qemu, only one should be needed, depending on the hardware on which you have to do virtualization. but, who knows, maybe I'm missing some use cases...</blockquote>
<pre>
Yes, so use plain qemu for ARM and other architectures.

My understanding is that the qemu-kvm codebase is optimized for 
*only* KVM usage, and thus some more generic optimizations (e.g.
for ARM and other non-KVM architectures) may not be present, 
while the exact opposite is true of the regular qemu codebase.
Therefore, the best approach would be to have only the "qemu-kvm"
package installed if you only need virtualization (i.e. x86*), 
or install only the regular "qemu" package if you only need to 
work with non-KVM-enabled architectures (e.g. ARM), or install 
both packages if you need to do both.

I'm attaching a tarball of the result of all discussion thus far.
Note that it changes KVMGROUP to "users" by default (as I suspect
the most common usecase here is a single-user devel box) and no
longer offers the option of building "all" targets -- regular qemu
should be used for that.

-RW
</pre>
</blockquote>
<p> </p>
<p>replacement package uploaded to slackbuilds.org</p>
<p>changes to package:</p>
<p>  default group changed from kvm to users</p>
<p>  default target changed to x86_64-softmmu</p>
<p>  target list feature (e.g. build all targets) no longer in package</p>
<p>  /usr/bin/qemu-system-x86_64 binary renamed to /usr/bin/qemu-kvm (don't forget to change your startup scripts!)</p>
<p>  README and qemu-SlackBuild reference QEMU for non-x86 CPU targets</p>
<p> </p>
<div> </div>
</body></html>