Re: [Qemu-devel] QEMU 3.0 ?

[Cornelia Huck]

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

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