From: Avi Kivity <avi@redhat.com>
To: qemu-devel@nongnu.org
Cc: aliguori@us.ibm.com
Subject: Re: [Qemu-devel] vga optmization
Date: Tue, 04 Nov 2008 09:23:50 +0200 [thread overview]
Message-ID: <490FF886.7060005@redhat.com> (raw)
In-Reply-To: <20081103173111.GC30410@poweredge.glommer>
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.
next prev parent reply other threads:[~2008-11-04 7:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 17:31 [Qemu-devel] vga optmization Glauber Costa
2008-11-03 17:43 ` Stefano Stabellini
2008-11-03 17:52 ` Glauber Costa
2008-11-03 18:06 ` Stefano Stabellini
2008-11-03 18:03 ` Blue Swirl
2008-11-03 18:14 ` Glauber Costa
2008-11-03 18:41 ` Blue Swirl
2008-11-03 18:47 ` Glauber Costa
2008-11-03 18:13 ` Fabrice Bellard
2008-11-03 18:18 ` Glauber Costa
2008-11-04 7:23 ` Avi Kivity [this message]
2008-11-04 9:31 ` andrzej zaborowski
2008-11-04 11:40 ` Stefano Stabellini
2008-11-04 13:43 ` Glauber Costa
2008-11-04 14:51 ` Avi Kivity
2008-11-04 14:52 ` Anthony Liguori
2008-11-04 14:55 ` Glauber Costa
2008-11-04 15:13 ` Stefano Stabellini
2008-11-04 20:42 ` Avi Kivity
2008-11-04 20:51 ` Anthony Liguori
2008-11-04 15:01 ` Stefano Stabellini
2008-11-04 20:28 ` Glauber Costa
2008-11-04 20:40 ` Anthony Liguori
2008-11-05 14:42 ` Stefano Stabellini
2008-11-07 11:15 ` Glauber Costa
2008-11-07 11:33 ` Stefano Stabellini
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=490FF886.7060005@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.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).