Re: [PATCH v5 07/34] KVM: x86: Activate master clock immediately on vCPU creation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional masterclock update causes O(N^2) overhead during VM creation
--

commit 8f4737a975ef2b2f510c7316ea3baa233e41c647
Author: David Woodhouse <dwmw@amazon.co.uk>

KVM: x86: Activate master clock immediately on vCPU creation

This commit updates vCPU creation to activate the master clock immediately,
rather than waiting for the first vCPU to process KVM_REQ_MASTERCLOCK_UPDATE.
This allows KVM_GET_CLOCK to return a valid host_tsc and realtime pair right
away without requiring a dummy vCPU run.

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index b7e5f6e3dc6c1..c1897d939da91 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13098,6 +13098,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
>  		return;
>  	vcpu_load(vcpu);
>  	kvm_synchronize_tsc(vcpu, NULL);
> +	if (!vcpu->kvm->arch.use_master_clock)
> +		kvm_update_masterclock(vcpu->kvm);

[Severity: High]
Does this cause an O(N^2) scaling issue during VM creation if the host 
clocksource doesn't support the masterclock?

If the host lacks masterclock support (for example, missing a TSC 
clocksource), vcpu->kvm->arch.use_master_clock remains false after the 
update. This means every subsequent vCPU creation will re-trigger 
kvm_update_masterclock() unnecessarily.

Since kvm_update_masterclock() makes requests for all existing vCPUs 
using kvm_make_all_cpus_request() and loops over them, creating N vCPUs 
would result in O(N^2) lock acquisitions and iterations. Could this 
cause noticeable latency regressions or soft lockups when booting large VMs?

>  	vcpu_put(vcpu);
>  
>  	/* poll control enabled by default */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608145455.89187-1-dwmw2@infradead.org?part=7