Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c

[Avi Kivity]

Jamie Lokier wrote:
> Avi Kivity wrote:
>   
> > Jamie Lokier wrote:
> >     
> > > But does the fact KVM doesn't use TCG prevent KVM from running some
> > > x86 modes correctly?  E.g. I gather 16-bit code is run by KVM using
> > > VM86 mode, which is not exactly correct.  It would be nice to have KVM
> > > acceleration but also complete and correct emulation, by switching to
> > > TCG for those modes.
> > >       
> > There is work in progress to make 16-bit emulation fully accurate.
> >     
>
> Ooh!  I want my Windows 95 to run in KVM :-)
> I'm curious, how is this planned to work?
>
> I'm having trouble thinking of how to do it without software emulation
> at some stage.
>
>   

By emulating all instructions that can't be virtualized.

> > Since TCG is not smp-safe, this is very problematic for smp guests.  You 
> > would have to stop virtualization on all vcpus and start tcg on all of 
> > them.  Performance would plummet.
> >     
>
> On the other hand, when running on a KVM-capable architecture
> combination, it is definitely possible to make TCG smp-safe because
> every guest atomic instruction has a corresponding host one.  It's
> practically a 1:1 instruction mapping on x86, which doesn't have many
> atomic instructions.  (Maybe harder on other archs).
>
>   

Maybe.  It's simpler to fix kvm not to require this.  I don't want kvm 
to be tied to qemu; when userspace tells kvm to run a vcpu, it means run 
the vcpu; not "run the vcpu unless there are some instructions you can't 
run for some undocumented reason".

> > There are ways of mitigating the high mmio cost with kvm.  For 
> > framebuffers, one can allow kvm direct access.  For other mmio, there's 
> > the 'coalesced mmio' support which allows mmio to be batched when this 
> > does not affect emulation accuracy and latency.
> >     
>
> Don't you still have to trap for each MMIO in order to collect the
> batch, except for REP instructions?  It's the traps which are expensive.
>
> Fortunately modern hardware tends to use DMA for data intensive
> things, and MMIO just to trigger DMA, and initialisation.
>   

In practice things work fine.  16-color modes are slow but only very old 
software was designed to work with them, so it expected the hardware to 
be slow.

--
error compiling committee.c: too many arguments to function