All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Brijesh Singh <brijesh.singh@amd.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged
Date: Thu, 14 Jan 2021 14:45:10 +0100	[thread overview]
Message-ID: <87pn277huh.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <1610623624-18697-1-git-send-email-wanpengli@tencent.com>

Wanpeng Li <kernellwp@gmail.com> writes:

> From: Wanpeng Li <wanpengli@tencent.com>
>
> The per-cpu vsyscall pvclock data pointer assigns either an element of the 
> static array hv_clock_boot (#vCPU <= 64) or dynamically allocated memory 
> hvclock_mem (vCPU > 64), the dynamically memory will not be allocated if 
> kvmclock vsyscall is disabled, this can result in cpu hotpluged fails in 
> kvmclock_setup_percpu() which returns -ENOMEM. This patch fixes it by not 
> assigning vsyscall pvclock data pointer if kvmclock vdso_clock_mode is not 
> VDSO_CLOCKMODE_PVCLOCK.
>
> Fixes: 6a1cac56f4 ("x86/kvm: Use __bss_decrypted attribute in shared variables")
> Reported-by: Zelin Deng <zelin.deng@linux.alibaba.com>
> Tested-by: Haiwei Li <lihaiwei@tencent.com>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Cc: stable@vger.kernel.org#v4.19-rc5+
> Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
> ---
>  arch/x86/kernel/kvmclock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index aa59374..0624290 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -296,7 +296,8 @@ static int kvmclock_setup_percpu(unsigned int cpu)
>  	 * pointers. So carefully check. CPU0 has been set up in init
>  	 * already.
>  	 */
> -	if (!cpu || (p && p != per_cpu(hv_clock_per_cpu, 0)))
> +	if (!cpu || (p && p != per_cpu(hv_clock_per_cpu, 0)) ||
> +	    (kvm_clock.vdso_clock_mode != VDSO_CLOCKMODE_PVCLOCK))
>  		return 0;

The comment above should probably be updated as it is not clear why we
check kvm_clock.vdso_clock_mode here. Actually, I would even suggest we
introduce a 'kvmclock_tsc_stable' global instead to avoid this indirect
check.

>  
>  	/* Use the static page for the first CPUs, allocate otherwise */

Also, would it be better if we just avoid cpuhp_setup_state() call in
this case? E.g. both these ideas combined (completely untested):

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index aa593743acf6..0827aef3ccb8 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -25,6 +25,7 @@
 
 static int kvmclock __initdata = 1;
 static int kvmclock_vsyscall __initdata = 1;
+static bool kvmclock_tsc_stable __ro_after_init = true;
 static int msr_kvm_system_time __ro_after_init = MSR_KVM_SYSTEM_TIME;
 static int msr_kvm_wall_clock __ro_after_init = MSR_KVM_WALL_CLOCK;
 static u64 kvm_sched_clock_offset __ro_after_init;
@@ -275,8 +276,10 @@ static int __init kvm_setup_vsyscall_timeinfo(void)
                return 0;
 
        flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
-       if (!(flags & PVCLOCK_TSC_STABLE_BIT))
+       if (!(flags & PVCLOCK_TSC_STABLE_BIT)) {
+               kvmclock_tsc_stable = false;
                return 0;
+       }
 
        kvm_clock.vdso_clock_mode = VDSO_CLOCKMODE_PVCLOCK;
 #endif
@@ -325,7 +328,8 @@ void __init kvmclock_init(void)
                return;
        }
 
-       if (cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "kvmclock:setup_percpu",
+       if (kvmclock_tsc_stable &&
+           cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "kvmclock:setup_percpu",
                              kvmclock_setup_percpu, NULL) < 0) {
                return;
        }

-- 
Vitaly


  reply	other threads:[~2021-01-14 13:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 11:27 [PATCH] KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged Wanpeng Li
2021-01-14 13:45 ` Vitaly Kuznetsov [this message]
2021-01-15  1:15   ` Wanpeng Li
2021-01-18 18:26     ` Paolo Bonzini
2021-01-19  0:28       ` Wanpeng Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pn277huh.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=brijesh.singh@amd.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.