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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9f0d0543-db41-fbb0-019c-7df5b9319c33@redhat.com>
Date:   Mon, 6 Sep 2021 13:22:49 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Zelin Deng <zelin.deng@...ux.alibaba.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] Guest system time jumps when new vCPUs is hot-added

On 28/04/21 04:22, Zelin Deng wrote:
> Hello,
> I have below VM configuration:
> ...
>      <vcpu placement='static' current='1'>2</vcpu>
>      <cpu mode='host-passthrough'>
>      </cpu>
>      <clock offset='utc'>
>          <timer name='tsc' frequency='3000000000'/>
>      </clock>
> ...
> After VM has been up for a few minutes, I use "virsh setvcpus" to hot-add
> second vCPU into VM, below dmesg is observed:
> [   53.273484] CPU1 has been hot-added
> [   85.067135] SMP alternatives: switching to SMP code
> [   85.078409] x86: Booting SMP configuration:
> [   85.079027] smpboot: Booting Node 0 Processor 1 APIC 0x1
> [   85.080240] kvm-clock: cpu 1, msr 77601041, secondary cpu clock
> [   85.080450] smpboot: CPU 1 Converting physical 0 to logical die 1
> [   85.101228] TSC ADJUST compensate: CPU1 observed 169175101528 warp. Adjust: 169175101528
> [  141.513496] TSC ADJUST compensate: CPU1 observed 166 warp. Adjust: 169175101694
> [  141.513496] TSC synchronization [CPU#0 -> CPU#1]:
> [  141.513496] Measured 235 cycles TSC warp between CPUs, turning off TSC clock.
> [  141.513496] tsc: Marking TSC unstable due to check_tsc_sync_source failed
> [  141.543996] KVM setup async PF for cpu 1
> [  141.544281] kvm-stealtime: cpu 1, msr 13bd2c080
> [  141.549381] Will online and init hotplugged CPU: 1
> 
> System time jumps from 85.101228 to 141.51.3496.
> 
> Guest:                                   KVM
> -----                                    ------
> check_tsc_sync_target()
> wrmsrl(MSR_IA32_TSC_ADJUST,...)
>                                           kvm_set_msr_common(vcpu,...)
>                                           adjust_tsc_offset_guest(vcpu,...) //tsc_offset jumped
>                                           vcpu_enter_guest(vcpu) //tsc_timestamp was not changed
> ...
> rdtsc() jumped, system time jumped
> 
> tsc_timestamp must be updated before go back to guest.
> 
> ---
> Zelin Deng (1):
>    KVM: x86: Update vCPU's hv_clock before back to guest when tsc_offset
>      is adjusted
> 
>   arch/x86/kvm/x86.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 

While Thomas is right in general, what you found is indeed a bug with 
the KVM->userspace API to set up the vCPU TSC adjust.  So I'm queueing 
the patch for 5.15.

Thanks,

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ