From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCaaZ-0007fb-TM for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:12:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCaaV-0007a7-0L for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:12:27 -0500 Received: from [199.232.76.173] (port=36900 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCaaU-0007Zs-6g for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:12:22 -0500 Received: from mail-bw0-f228.google.com ([209.85.218.228]:48304) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCaaT-0001HL-RT for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:12:22 -0500 Received: by bwz28 with SMTP id 28so5758250bwz.17 for ; Mon, 23 Nov 2009 07:12:20 -0800 (PST) Message-ID: <4B0AA64F.6040703@codemonkey.ws> Date: Mon, 23 Nov 2009 09:12:15 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <1258983457-sup-5031@blackpad.lan.raisama.net> <4B0A9A64.2090109@redhat.com> <20091123150221.GF4485@blackpad.lan.raisama.net> In-Reply-To: <20091123150221.GF4485@blackpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel Eduardo Habkost wrote: > The pvclock MSRs are an example: if the guest is not using pvclock, not > restoring the MSRs won't make any difference. Strictly speaking, not > migrating them is wrong, but the user may argue that they know it won't > impact their guest OS, and that they want to take the risk. Once you start dealing with issues of risk vs. benefit, it's a policy and belongs in the management layer. We don't make risk vs. benefit assessments in qemu. We defer those types of decisions. Today, we only succeed migration when we know it will be successful. We could allow a management tool to override this check such that it could implement such a policy. But that's a really dangerous option to offer. > Also, on the pvclock MSR case (and probably others), any argument > against doing backward migration would also be valid against doing > forward migration when the source process doesn't have the fix yet, > because the pvclock MSRs won't be migrated anyway. Forward migration is > as broken as backward migration, but we don't prevent migration on that > direction. > A bug that is visible to a guest is no longer a bug, but a feature that has to be supported for as long as that release is supported. If we feel that it's too dangerous of a bug, then we need to fail gracefully and refuse to load that state on any other system forcing a proper shutdown/startup for migration to a new version of qemu. For the purposes of compatibility, it is something that we have to preserve. In this case, you're introducing two MSRs that are readable and writable by a guest. If you migrate all of the sudden you lose that MSRs content. You cannot have live migration cause an MSR to disappear regardless of what the purpose of that MSR is. Regards, Anthony Liguori