[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009
Date: Mon, 26 Jan 2009 14:42:39 -0600
User-agent: Thunderbird (X11/20090105)

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]