From: Glauber Costa <glommer@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009
Date: Wed, 21 Jan 2009 09:46:26 -0200 [thread overview]
Message-ID: <20090121114626.GA628@poweredge.glommer> (raw)
In-Reply-To: <200901210543.07538.paul@codesourcery.com>
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)
next prev parent reply other threads:[~2009-01-21 11:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 18:50 [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 1/6] remove smaller slots if registering a bigger one Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 2/6] re-register whole area upon lfb unmap Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 3/6] isolate io handling routine Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 4/6] replace cpu_physical_memory_rw Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 5/6] hook cpu_register_physical_mem Glauber Costa
2009-01-20 18:51 ` [Qemu-devel] [PATCH 6/6] cache slot lookup Glauber Costa
2009-01-20 20:24 ` [Qemu-devel] [PATCH 4/6] replace cpu_physical_memory_rw Avi Kivity
2009-01-20 20:33 ` Glauber Costa
2009-01-21 5:43 ` [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 Paul Brook
2009-01-21 11:46 ` Glauber Costa [this message]
2009-01-21 17:16 ` Ian Jackson
2009-01-21 18:40 ` Glauber Costa
2009-01-22 0:11 ` Paul Brook
2009-01-22 14:02 ` Glauber Costa
2009-01-26 20:42 ` Anthony Liguori
2009-01-21 19:26 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090121114626.GA628@poweredge.glommer \
--to=glommer@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).