Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009

[Anthony Liguori]

Paul Brook wrote:
> On Wednesday 21 January 2009, Ian Jackson wrote:
>   
> > > In all my laziness I agree that we should not be duplicating
> > > things. Hence why, for example, I tried to commonize the I/O
> > > functions: which are the same. (and I see no benefit in changing the
> > > way KVM keeps track of I/O regions in the near future)
> > >       
> > I think the KVM and Xen approaches are probably similar enough that we
> > can share this code.  I'll have to look at it in detail at some point,
> > which I don't have time to do right now or necessarily even soon.
> >     
>
> I don't see a reason why these need to be different. They're all doing 
> basically the same thing. The low level implementation details ara a bit 
> different, but in principle kvm, xen and tcg all need to to exactly the same 
> thing: Figure out what a particular physical address is mapped to.
>   

That's a bit of a simplification.  TCG needs a fair bit more than what 
KVM and Xen needs.  TCG needs to keep track of any write operations to 
memory that could possibly be translated to flush the translation 
caches.  TCG also maintains a software TLB and therefore is going to 
have a different set of sensitivities to the performance characteristics 
of RAM lookup since the performance overhead occurs on every software 
TLB miss.

Conversely, KVM needs to only keep track of MMIO regions since the 
kernel tracks RAM regions.  There is no software TLB so the cost of a 
TLB miss is neglible.  There is no concern about icache flushing because 
the hardware will take care of this.

That said, it may be possible to develop a unified implementation.  
However, it has been expressed previously (by Fabrice, among others) 
that there is a desire to decouple the CPU execution code (be it TCG or 
KVM) from the rest of QEMU so that you could even plug-in new CPU 
emulators rather easily.  That is what this patch series is doing 
primarily, establishing that interface.

> As discussed previously, l1_phys_map is not a good solution, and needs to go 
> away. Anypatch that involves independent code paths for kvm and tcg 
> because "the tcg code doesn't work for kvm" sounds a lot like lazyness. The 
> real solution is to fix the current implementation rather than adding a new 
> one.
>   

Laziness is distinctly different from incremental development.  We know 
this code will do well for KVM, so let's use it for KVM and iron out any 
problems.  After someone has done the work of doing performance 
measurement on the TCG code and adjusting the slot code so that it can 
be hooked appropriate for TCG, we can convert TCG to using it, if 
appropriate.

At the end of the day, we're talking about 200-300 lines of code.  I'm 
not hugely concerned that we're duplicating code within QEMU.

Regards,

Anthony Liguori

> Paul
>
>
>