From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCwOc-0000yf-SP for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:29:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCwOY-0000v8-0H for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:29:34 -0500 Received: from [199.232.76.173] (port=42704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCwOW-0000uq-4h for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:29:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16897) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCwOV-0004VR-OI for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:29:28 -0500 Date: Tue, 24 Nov 2009 16:26:49 +0200 From: "Michael S. Tsirkin" Message-ID: <20091124142649.GO2405@redhat.com> 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> <4B0AA64F.6040703@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0AA64F.6040703@codemonkey.ws> Subject: [Qemu-devel] Re: Re: Live migration protocol, device features, ABIs and other beasts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel On Mon, Nov 23, 2009 at 09:12:15AM -0600, Anthony Liguori wrote: > 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 Same with having MSRs appear, surely? -- MST