On Fri, 2022-02-25 at 13:10 +0100, Paolo Bonzini wrote: > > Queued, but I'd rather have a subject that calls out that max_tsc_khz > needs a replacement at vCPU creation time. In fact, the real change > (and bug, and fix) is in kvm_arch_vcpu_create(), while the subject > mentions only the change in kvm_timer_init(). In https://lore.kernel.org/kvm/e7be32b06676c7ebf415d9deea5faf50aa8c0785.camel@xxxxxxxxxxxxx/T/ last night I was coming round to the idea that we might want a KVM-wide default frequency which is settable from userspace and is used instead of max_tsc_khz anyway. I also have questions about the use case for the above patch.... if this is a clean boot and you're just starting to host guests, surely we can wait for the time it takes for the TSC synchronization to complete? And if this is a live update scenario, where we pause the guests, kexec into a new kernel, then resume the "migrated" guests again... why in $DEITY's name isn't the precise TSC frequency being handed over from kernel#1 to kernel#2 over the kexec so that it's known from the start?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
