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

[Paul Brook <paul@codesourcery.com>]

On Wednesday 21 January 2009, Ian Jackson wrote:
> Glauber Costa writes ("Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory 
functions -v1.0-2009"):
> > On Wed, Jan 21, 2009 at 05:43:06AM +0000, Paul Brook wrote:
> > > 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".
>
> For what it's worth I can definitely see where Glauber is coming from.
> The Xen tree also has a replacement implementations of things like
> cpu_register_io_memory, for very similar reasons.
>
> > 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.

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.

Paul