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

[Anthony Liguori]

Jamie Lokier wrote:
> Firstly:
>
> That doesn't make sense: why would you do an expensive TCG translation
> every time you hit the same code?  After the first encounter, if the
> code page hasn't been modified, it should be a TB cache lookup to
> already translated code.
>   

Except that once you run under KVM again, you lose all dirty information 
and you have to invalidate all TBs.

FWIW, a few years ago, we implemented this concept with QEMU and Xen.  
That's where my data is coming from.

> I'm guessing the cost of TB cache lookup is much closer to 3k than
> 300k cycles, maybe even lower...
>   

You're guessing and it doesn't matter anyway because the TB cache has to 
be invalidated.

> Secondly:
>
> In these cases, you can use a special fast translation (when it's not
> cached) which just copies the instructions 1:1 from the guest, simply
> converting the special instructions (MMIO, anything else needing it)
> to helper calls.  That's possible because you know the host is ture
> architeccompatible with the guest, as it's running KVM.
>   

You can't copy 1:1 because the instructions aren't 1:1.  Only trivial 
instructions that manipulate registers remain the same but even then, 
you have to do register renaming and on the x86 this probably means 
you'll have to spill some registers because you have so few.  Any memory 
reference (mov, push, pop, etc.) must be translated to a different 
instruction because you don't have a virtual address that can be 
accessed directly so you need a hook to simulate a tlb miss.

You can preserve atomicity if you try hard enough, but it certainly 
isn't a 1:1 translation in softmmu mode.

> > If you also consider all the potential locking issues with SMP guests, I 
> > think it's pretty likely that there are few cases where dropping to TCG 
> > is going to be a net performance win.
> >     
>
> VMware claimed otherwise when Intel first brought out CPU support for
> virtualisation.
>   

That's just not true.  The paper that you're most likely referencing was 
much more nuanced than that and the hardware has improved dramatically 
since then.

> SMP works fine if you map guest instructions 1:1 to host instructions
> with helper calls for special cases.  Even atomics, load-locked
> sequences and complex weak memory ordering things would behave
> correctly.
>   

You can't translate 1:1 so your argument falls apart.

Regards,

Anthony Liguori

> Oops, I believe I just argued for keeping the TB cache and code
> translation but not using TCG :-)
>
> -- Jamie
>