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
