From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KxGGV-0006wZ-5E
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:23:51 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KxGGS-0006v9-Ve
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:23:50 -0500
Received: from [199.232.76.173] (port=48655 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KxGGS-0006v2-Ea
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:23:48 -0500
Received: from mx2.redhat.com ([66.187.237.31]:54891)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1KxGGS-0007vx-0R
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 02:23:48 -0500
Message-ID: <490FF886.7060005@redhat.com>
Date: Tue, 04 Nov 2008 09:23:50 +0200
From: Avi Kivity <avi@redhat.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=ISO-8859-1; format=flowed
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

Glauber Costa wrote:
> 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
>
>   
> +int cpu_physical_memory_get_dirty(ram_addr_t addr,
> +                                                int dirty_flags)
> +{
> +    int is_dirty = 0;
> +    is_dirty = phys_ram_dirty[addr >> TARGET_PAGE_BITS] & dirty_flags;
> +    if (is_dirty)
> +        goto out;
> +#ifdef CONFIG_KVM
> +    if (kvm_enabled())
> +        is_dirty = kvm_physical_memory_get_dirty(addr);
> +        /* to make it usable below */
> +        is_dirty = !!is_dirty * 0xff;
> +#endif
> +out:
> +    return is_dirty;
> +}
> +
>   

The kvm dirty bitmap and qemu dirty bitmap are different.  'qemu dirty' 
means 'written to since hte last time the dirty bit was cleared', while 
'kvm dirty' means 'written to since the last time the bitmap was 
synchronized'.  So the qemu bitmap is stickier than the kvm bitmap.

The current code accounts for that by merging the kvm bitmap into the 
qemu bitmap, but you're losing some information here.  It doesn't matter 
for vga, since you're clearing the dirty bit immediately anyway, but it 
will matter for other uses (example, live migration with the vga 
optimization enabled).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.