qemu-devel
[Top][All Lists]
Advanced

[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: Glauber Costa
Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009
Date: Wed, 21 Jan 2009 09:46:26 -0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Jan 21, 2009 at 05:43:06AM +0000, Paul Brook wrote:
> On Tuesday 20 January 2009, Glauber Costa wrote:
> > This series is not very different from the last one that did it.
> > Just bringing it back from my vacations. Idea is to replace tcg
> > memory functions with kvm's, selectable at runtime. Right now
> > we use a conditional selection. In the future, we might use
> > function pointers to allow for easy coupling of any hypervisor.
> 
> I dislike that you're introducing two different ways or doing the same thing. 
>  
> Duplicating all the memory region tracking code seems like a bad way to solve 
> this problem.
That's because I think I'm introducing two different ways of doing two different
things that just happens to fall under the same name of "memory tracking".

tcg has a lot of stuff that hypervisors won't need, such as keeping track of a 
tlb,
invalidating memory for the code generator, etc. It is all heavily coupled, and
attempts to make it less like it, just led to a bigger number of hooks, most of 
them
which were empty hooks. (you might remember the old QEMUAccel approach we took).

Before this patchset, memory registration for KVM is:
   * kvm_set_phys_mem
   * tcg stuff.

After this patchset, it is:
   * kvm_set_phys_mem
   * end of story.

So right now, tcg memory handling is pure overhead for us. Keeping things
separated gives opportunity for better specific optimization when possible,
not to mention the fact that the possibility that we break tcg while inoccently
hacking KVM drops significantly in this area.

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)




reply via email to

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