On Thu, Oct 22, 2015 at 04:45:21PM -0200, Eduardo Habkost wrote: > On Tue, Oct 20, 2015 at 03:22:51PM +0800, Haozhong Zhang wrote: > > This patchset enables QEMU to save/restore vcpu's TSC rate during the > > migration. When cooperating with KVM which supports TSC scaling, guest > > programs can observe a consistent guest TSC rate even though they are > > migrated among machines with different host TSC rates. > > > > A pair of cpu options 'save-tsc-freq' and 'load-tsc-freq' are added to > > control the migration of vcpu's TSC rate. > > The requirements and goals aren't clear to me. I see two possible use > cases, here: > > 1) Best effort to keep TSC frequency constant if possible (but not > aborting migration if not possible). This would be an interesting > default, but a bit unpredictable. > 2) Strictly ensuring TSC frequency stays constant on migration (and > aborting migration if not possible). This would be an useful feature, > but can't be enabled by default unless both hosts have the same TSC > frequency or support TSC scaling. > > Which one(s) you are trying to implement? > The former. I agree that it's unpredictable if setting vcpu's TSC frequency to the migrated value is enabled by default (but not in this patchset). The cpu option 'load-tsc-freq' is introduced to allow users to enable this behavior if they do know the underlying KVM and CPU support TSC scaling. In this way, I think the behavior is predictable as users do know what they are doing. > In other words, what is the right behavior when KVM_SET_TSC_KHZ fails or > KVM_CAP_TSC_CONTROL is not available? We can't answer that question if > the requirements and goals are not clear. > If KVM_CAP_TSC_CONTROL is unavailable, QEMU and KVM will use the host TSC frequency as vcpu's TSC frequency. If KVM_CAP_TSC_CONTROL is available and KVM_SET_TSC_KHZ fails, the setting of TSC frequency will fail and abort either the VM creation (this is the case for cpu option 'tsc-freq') or the migration. > Once we know what exactly is the goal, we could enable the new mode with > a single option, instead of raw options to control migration stream > loading/saving. > Saving vcpu's TSC frequency does not depend on TSC scaling but the loading does. And that is why I introduce two cpu options to control them separately. Haozhong > > > * By default, the migration of vcpu's TSC rate is enabled only on > > pc-*-2.5 and newer machine types. If the cpu option 'save-tsc-freq' > > is present, the vcpu's TSC rate will be migrated from older machine > > types as well. > > * Another cpu option 'load-tsc-freq' controls whether the migrated > > vcpu's TSC rate is used. By default, QEMU will not use the migrated > > TSC rate if this option is not present. Otherwise, QEMU will use > > the migrated TSC rate and override the TSC rate given by the cpu > > option 'tsc-freq'. > > > > Changes in v2: > > * Add a pair of cpu options 'save-tsc-freq' and 'load-tsc-freq' to > > control the migration of vcpu's TSC rate. > > * Move all logic of setting TSC rate to target-i386. > > * Remove the duplicated TSC setup in kvm_arch_init_vcpu(). > > > > Haozhong Zhang (3): > > target-i386: add a subsection for migrating vcpu's TSC rate > > target-i386: calculate vcpu's TSC rate to be migrated > > target-i386: load the migrated vcpu's TSC rate > > > > include/hw/i386/pc.h | 5 +++++ > > target-i386/cpu.c | 2 ++ > > target-i386/cpu.h | 3 +++ > > target-i386/kvm.c | 61 +++++++++++++++++++++++++++++++++++++++++++-------- > > target-i386/machine.c | 19 ++++++++++++++++ > > 5 files changed, 81 insertions(+), 9 deletions(-) > > > > -- > > 2.4.8 > > > > -- > Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
