From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Merging KVM live migration upstream Date: Fri, 01 May 2009 13:16:52 +0200 Message-ID: <49FADA24.2020205@web.de> References: <49FABCF2.70909@web.de> <49FAD6CC.9040708@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C64F6BC118571C1C21D4125" Cc: Uri Lublin , Anthony Liguori , kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:58657 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758728AbZEALRB (ORCPT ); Fri, 1 May 2009 07:17:01 -0400 In-Reply-To: <49FAD6CC.9040708@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C64F6BC118571C1C21D4125 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > 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. >> >> =20 >=20 > These date from the bad old days where we relied on phys_ram_base. I > think this is obsolete. >=20 > Since we reserve these memory addresses, it won't do any harm, but we > can certainly remove them. That's great, will drop it. >=20 >> 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? >> =20 >=20 > Note the dependency on current_addr: this is meant to happen every time= > we cycle through all memory, so it doesn't fit in > cpu_physical_memory_get_dirty(). Yes, I realized that there is already cpu_physical_sync_dirty_bitmap(), and I will simply use this. >=20 >> And does anyone knows further migration-related hunks that are missing= >> upstream (except for the KVM hook in >> cpu_physical_memory_set_dirty_tracking)? >> >> =20 >=20 > We need to make sure vga plays well with this, like we discussed. Already implemented in ~30 additional LOC. Just have to test the whole series (found some more things to clean up) Jan --------------enig0C64F6BC118571C1C21D4125 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkn62ioACgkQniDOoMHTA+mGWACcDLNOizuBZnSpq3xkXPdmlMoX vlYAn3j124Q/tNlGDTk8fCXZxQ8pezcF =oQmD -----END PGP SIGNATURE----- --------------enig0C64F6BC118571C1C21D4125--