From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kx3PQ-0004Ep-Fb
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:40:12 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kx3PO-0004CQ-Ap
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:40:11 -0500
Received: from [199.232.76.173] (port=43636 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kx3PO-0004CB-2x
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:40:10 -0500
Received: from smtp.eu.citrix.com ([62.200.22.115]:11400)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Kx3PN-0005a8-TZ
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:40:10 -0500
Message-ID: <490F3838.8010401@eu.citrix.com>
Date: Mon, 03 Nov 2008 17:43:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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=UTF-8
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: qemu-devel@nongnu.org
Cc: aliguori@us.ibm.com

Can we try to avoid any if (kvm_enabled()) in the vga code and use some
kind of more generic hook instead?
Xen has some very similar changes to the vga code, it would be nice to
merge them as well.

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
> 
>