From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kx3wE-0007Gm-8j
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:14:06 -0500
Received: from [199.232.76.173] (port=45836 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kx3wD-0007G0-QX
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:14:05 -0500
Received: from mx1.polytechnique.org ([129.104.30.34]:52540)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1Kx3wD-0002zl-Ek
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:14:05 -0500
Message-ID: <490F3F64.30204@bellard.org>
Date: Mon, 03 Nov 2008 19:13:56 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] vga optmization
References: <20081103173111.GC30410@poweredge.glommer>
In-Reply-To: <20081103173111.GC30410@poweredge.glommer>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Glauber Costa <glommer@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org

Glauber Costa wrote:
> Hi guys,
> 
> this is a port of current kvm vga memory optimization to our new
> infrastructure proposed by anthony. It's goal is to use as few
> kvm specific hooks as possible. In fact, the only one I'm relying
> on is enabling/disabling of logging. The rest, is pretty much general.
> 
> We map the linear frame buffer area as RAM, and then use dirty tracking
> to decide whether or not to update it. To be consistent with qemu,
> this version, differently from upstream kvm, tracks memory based on its
> physical address, represented by vram_offset, instead of vram_ptr, or
> any other construct.
> 
> Let me know what you think

Why don't you modify the lower level QEMU dirty bits handling functions
to be consistent with the KVM dirty bits ? By doing that you can avoid
patching the device drivers and have smaller code. The fact that KVM use
physical memory addresses is not a problem if you can convert the ram
addresses to physical memory addresses (in most cases there is only one
physical address corresponding to one RAM address).

And if KVM does not use the dynamic translator during large amount of
time it might be worth bypassing most of the QEMU dirty bits handling
system to use only the KVM system in order to get better performance.

Regards,

Fabrice.