On 05/08/20 18:06, Oliver Upton wrote:
> On Tue, Jul 28, 2020 at 11:33 AM Oliver Upton <oupton@xxxxxxxxxx> wrote:
>>
>> On Tue, Jul 21, 2020 at 8:26 PM Oliver Upton <oupton@xxxxxxxxxx> wrote:
>>>
>>> To date, VMMs have typically restored the guest's TSCs by value using
>>> the KVM_SET_MSRS ioctl for each vCPU. However, restoring the TSCs by
>>> value introduces some challenges with synchronization as the TSCs
>>> continue to tick throughout the restoration process. As such, KVM has
>>> some heuristics around TSC writes to infer whether or not the guest or
>>> host is attempting to synchronize the TSCs.
>>>
>>> Instead of guessing at the intentions of a VMM, it'd be better to
>>> provide an interface that allows for explicit synchronization of the
>>> guest's TSCs. To that end, this series introduces the
>>> KVM_{GET,SET}_TSC_OFFSET ioctls, yielding control of the TSC offset to
>>> userspace.
>>>
>>> v2 => v3:
>>> - Mark kvm_write_tsc_offset() as static (whoops)
>>>
>>> v1 => v2:
>>> - Added clarification to the documentation of KVM_SET_TSC_OFFSET to
>>> indicate that it can be used instead of an IA32_TSC MSR restore
>>> through KVM_SET_MSRS
>>> - Fixed KVM_SET_TSC_OFFSET to participate in the existing TSC
>>> synchronization heuristics, thereby enabling the KVM masterclock when
>>> all vCPUs are in phase.
>>>
>>> Oliver Upton (4):
>>> kvm: x86: refactor masterclock sync heuristics out of kvm_write_tsc
>>> kvm: vmx: check tsc offsetting with nested_cpu_has()
>>> selftests: kvm: use a helper function for reading cpuid
>>> selftests: kvm: introduce tsc_offset_test
>>>
>>> Peter Hornyack (1):
>>> kvm: x86: add KVM_{GET,SET}_TSC_OFFSET ioctls
>>>
>>> Documentation/virt/kvm/api.rst | 31 ++
>>> arch/x86/include/asm/kvm_host.h | 1 +
>>> arch/x86/kvm/vmx/vmx.c | 2 +-
>>> arch/x86/kvm/x86.c | 147 ++++---
>>> include/uapi/linux/kvm.h | 5 +
>>> tools/testing/selftests/kvm/.gitignore | 1 +
>>> tools/testing/selftests/kvm/Makefile | 1 +
>>> .../testing/selftests/kvm/include/test_util.h | 3 +
>>> .../selftests/kvm/include/x86_64/processor.h | 15 +
>>> .../selftests/kvm/include/x86_64/svm_util.h | 10 +-
>>> .../selftests/kvm/include/x86_64/vmx.h | 9 +
>>> tools/testing/selftests/kvm/lib/kvm_util.c | 1 +
>>> tools/testing/selftests/kvm/lib/x86_64/vmx.c | 11 +
>>> .../selftests/kvm/x86_64/tsc_offset_test.c | 362 ++++++++++++++++++
>>> 14 files changed, 550 insertions(+), 49 deletions(-)
>>> create mode 100644 tools/testing/selftests/kvm/x86_64/tsc_offset_test.c
>>>
>>> --
>>> 2.28.0.rc0.142.g3c755180ce-goog
>>>
>>
>> Ping :)
>
> Ping
Hi Oliver,
I saw these on vacation and decided I would delay them to 5.10. However
they are definitely on my list.
I have one possibly very stupid question just by looking at the cover
letter: now that you've "fixed KVM_SET_TSC_OFFSET to participate in the
existing TSC synchronization heuristics" what makes it still not
"guessing the intentions of a VMM"? (No snark intended, just quoting
the parts that puzzled me a bit).
My immediate reaction was that we should just migrate the heuristics
state somehow, but perhaps I'm missing something obvious.
Paolo
