Re: [Qemu-devel] QEMU 3.0 ?

[Daniel P. Berrange]

On Thu, Nov 23, 2017 at 01:39:24PM +0100, Cornelia Huck wrote:
> On Thu, 23 Nov 2017 13:26:14 +0100
> Paolo Bonzini <address@hidden> wrote:
> 
> > On 23/11/2017 13:09, Cornelia Huck wrote:
> > > On Thu, 23 Nov 2017 13:05:33 +0100
> > > Paolo Bonzini <address@hidden> wrote:
> > >   
> > >> On 23/11/2017 12:57, Thomas Huth wrote:  
> > >>> On 23.11.2017 12:17, Paolo Bonzini wrote:    
> > >>>> On 23/11/2017 11:57, Thomas Huth wrote:    
> > >>> [...]    
> > >>>>> I've put "--accel kvm:hax:tcg" also on the doable list since I don't
> > >>>>> remember any objections to that idea so far -- feel free to move it to
> > >>>>> the controversial list instead if you think it needs more discussion. 
> > >>>>>    
> > >>>>
> > >>>> "hax" is very far from feature parity with TCG, it doesn't even support
> > >>>> CPUID (-cpu).  "-accel kvm:hvf:tcg" could be a possibility, but only if
> > >>>> we have resources to test it.  As far as I know the only active x86
> > >>>> developer who owns a Mac is Igor?    
> > >>>
> > >>> hvf hasn't been merged yet ... do you expect it to hit master after 2.11
> > >>> has been released?    
> > >>
> > >> Yes, more or less.
> > >>  
> > >>> Otherwise, we should maybe rather simply go with
> > >>> "--accel kvm:tcg"?    
> > >>
> > >> Yes, HVF can come later.  
> > > 
> > > This switch sounds like something we can easily do for the next
> > > release; I'd hope that anyone explicitly requiring tcg already
> > > specifies it.  
> > 
> > I seriously doubt that.  Most people are probably using a
> > distro-provided qemu-kvm script for KVM, and qemu-system-x86_64 for TCG.
> >  In fact, that is probably the best of both worlds for anybody who
> > doesn't compile its own QEMU; and since KVM is Linux-only, there are
> > very few non-developers in the intersection of "compile its own QEMU"
> > and "use KVM".
> 
> I'm wondering how many people want to run e.g. x86_64-on-x86_64
> _without_ using an available kvm (and I expect those people to
> explicitly specify tcg).

Libvirt at least always explicitly gives an --accel option, so the
question is only for people who directly run qemu.


> > And in fact that is the main reason why have never bothered switching
> > the default... only RHEL does it, because it ships the QEMU binary as
> > qemu-kvm rather than qemu-system-xxx plus a wrapper script.
> > 
> > Perhaps we could:
> > 
> > 1) look for "qemu-{kvm,hvf,hax}" in argv[0] and change the "-accel" default?
> > 
> > 2) change "make install" to install one or more of qemu-kvm/hvf/hax
> > based on target architecture and OS.
> > 
> > Then distros can do away with the script and Windows/Mac users can learn
> > to use qemu-hvf and qemu-hax.
> 
> I'm not sure I like that. For me, qemu-kvm comes with the connotation
> of "there used to be a fork of qemu for kvm usage, and we stuck with
> the name because it is likely scattered through scripts".

Yes, qemu-kvm is a historical artifact in Fedora solely because of the
previous fork. We can't easily get rid of it because the path is encoded
in libvirt XML files and countless end user scripts/configs.

In RHEL it exists for similar historical reasons, but we explicitly want
to keep it, since RHEL only ships KVM, this allows people to optionally
install a full QEMU for TCG usage in parallel.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|