lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 10 Dec 2020 12:48:20 +0100 From: Paolo Bonzini <pbonzini@...hat.com> To: Maxim Levitsky <mlevitsk@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Oliver Upton <oupton@...gle.com> Cc: kvm list <kvm@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>, Jim Mattson <jmattson@...gle.com>, Wanpeng Li <wanpengli@...cent.com>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, Vitaly Kuznetsov <vkuznets@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>, Sean Christopherson <sean.j.christopherson@...el.com>, open list <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>, Joerg Roedel <joro@...tes.org>, Borislav Petkov <bp@...en8.de>, Shuah Khan <shuah@...nel.org>, Andrew Jones <drjones@...hat.com>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org> Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE On 08/12/20 18:08, Maxim Levitsky wrote: >> Even if you support TSCADJUST and let the guest write to it does not >> change the per guest offset at all. TSCADJUST is per [v]CPU and adds on >> top: >> >> tscvcpu = tsc_host + guest_offset + TSC_ADJUST >> >> Scaling is just orthogonal and does not change any of this. > > I agree with this, and I think that this is what we will end up doing. > Paulo, what do you think about this? Yes, you can have a VM ioctl that saves/restores cur_tsc_nsec and cur_tsc_write. The restore side would loop on all vcpus. However, it is not so easy: 1) it would have to be usable only if KVM_X86_QUIRK_TSC_HOST_ACCESS is false, 2) it would fail if kvm->arch.nr_vcpus_matched_tsc == kvm->online_vcpus (which basically means that userspace didn't mess up the TSC configuration). If not, it would return -EINVAL. Also, while at it let's burn and pour salt on the support for KVM_SET_TSC_KHZ unless TSC scaling is supported, together with vcpu->tsc_catchup and all the "tolerance" crap that is in kvm_set_tsc_khz. And initialize vcpu->arch.virtual_tsc_khz to kvm->arch.last_tsc_khz before calling kvm_synchronize_tsc. Paolo
Powered by blists - more mailing lists