From: Anthony Liguori <anthony@codemonkey.ws>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Avi Kivity <avi@redhat.com>, Uri Lublin <uril@redhat.com>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: Merging KVM live migration upstream
Date: Fri, 01 May 2009 13:58:28 -0500 [thread overview]
Message-ID: <49FB4654.6020204@codemonkey.ws> (raw)
In-Reply-To: <49FABCF2.70909@web.de>
Jan Kiszka wrote:
> Avi or Uri,
>
> could you explain the first and third hunk? Why are they needed in
> qemu-kvm, and will we also need something comparable upstream? They do
> not look very beautiful.
>
This is leftovers from v1 loading. It used to be that we saved the vga
buffer independently before slot tracking was as sophisticated in qemu
as it is today. We don't restore v1 vga that would contain this section
though so it's basically dead code.
I'd just remove it personally.
> The second hunk, I guess, should become a kvm hook to
> cpu_physical_memory_get_dirty - or is this too costly for other users of
> this inline function?
>
> And does anyone knows further migration-related hunks that are missing
> upstream (except for the KVM hook in
> cpu_physical_memory_set_dirty_tracking)?
>
The cpu_save/cpu_load additions.
> Jan
>
> --- qemu/vl.c
> +++ qemu-kvm/vl.c
> @@ -3097,6 +3204,8 @@ static int ram_load_v1(QEMUFile *f, void
> if (qemu_get_be32(f) != last_ram_offset)
> return -EINVAL;
> for(i = 0; i < last_ram_offset; i+= TARGET_PAGE_SIZE) {
> + if (kvm_enabled() && (i>=0xa0000) && (i<0xc0000)) /* do not access video-addresses */
> + continue;
> ret = ram_get_page(f, qemu_get_ram_ptr(i), TARGET_PAGE_SIZE);
> if (ret)
> return ret;
> @@ -3183,6 +3292,15 @@ static int ram_save_block(QEMUFile *f)
> int found = 0;
>
> while (addr < last_ram_offset) {
> + if (kvm_enabled() && current_addr == 0) {
> + int r;
> + r = kvm_update_dirty_pages_log();
> + if (r) {
> + fprintf(stderr, "%s: update dirty pages log failed %d\n", __FUNCTION__, r);
> + qemu_file_set_error(f);
> + return 0;
> + }
> + }
> if (cpu_physical_memory_get_dirty(current_addr, MIGRATION_DIRTY_FLAG)) {
> uint8_t *p;
>
> @@ -3273,6 +3391,8 @@ static int ram_load_dead(QEMUFile *f, vo
> if (ram_decompress_open(s, f) < 0)
> return -EINVAL;
> for(i = 0; i < last_ram_offset; i+= BDRV_HASH_BLOCK_SIZE) {
> + if (kvm_enabled() && (i>=0xa0000) && (i<0xc0000)) /* do not access video-addresses */
> + continue;
> if (ram_decompress_buf(s, buf, 1) < 0) {
> fprintf(stderr, "Error while reading ram block header\n");
> goto error;
>
>
prev parent reply other threads:[~2009-05-01 18:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 9:12 Merging KVM live migration upstream Jan Kiszka
2009-05-01 11:02 ` Avi Kivity
2009-05-01 11:16 ` Jan Kiszka
2009-05-01 18:58 ` Anthony Liguori [this message]
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=49FB4654.6020204@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=uril@redhat.com \
/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