The hrtimer is initialized in the KVM_XEN_VCPU_SET_ATTR ioctl. That caused
problem in the past, because the hrtimer can be initialized multiple times,
which was fixed by commit af735db31285 ("KVM: x86/xen: Initialize Xen timer
only once"). This commit avoids initializing the timer multiple times by
checking the field 'function' of struct hrtimer to determine if it has
already been initialized.

Instead of "abusing" the 'function' field, move the hrtimer initialization
into kvm_xen_init_vcpu() so that it will only be initialized once.

Signed-off-by: Nam Cao <namcao@linutronix.de>
---
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
---
 arch/x86/kvm/xen.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 622fe24da910..c386fbe6b58d 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -1070,9 +1070,6 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
 			break;
 		}
 
-		if (!vcpu->arch.xen.timer.function)
-			kvm_xen_init_timer(vcpu);
-
 		/* Stop the timer (if it's running) before changing the vector */
 		kvm_xen_stop_timer(vcpu);
 		vcpu->arch.xen.timer_virq = data->u.timer.port;
@@ -2235,6 +2232,7 @@ void kvm_xen_init_vcpu(struct kvm_vcpu *vcpu)
 	vcpu->arch.xen.poll_evtchn = 0;
 
 	timer_setup(&vcpu->arch.xen.poll_timer, cancel_evtchn_poll, 0);
+	kvm_xen_init_timer(vcpu);
 
 	kvm_gpc_init(&vcpu->arch.xen.runstate_cache, vcpu->kvm);
 	kvm_gpc_init(&vcpu->arch.xen.runstate2_cache, vcpu->kvm);
-- 
2.39.5

On Mon, Oct 28, 2024, Nam Cao wrote:
> The hrtimer is initialized in the KVM_XEN_VCPU_SET_ATTR ioctl. That caused
> problem in the past, because the hrtimer can be initialized multiple times,
> which was fixed by commit af735db31285 ("KVM: x86/xen: Initialize Xen timer
> only once"). This commit avoids initializing the timer multiple times by
> checking the field 'function' of struct hrtimer to determine if it has
> already been initialized.
> 
> Instead of "abusing" the 'function' field, move the hrtimer initialization
> into kvm_xen_init_vcpu() so that it will only be initialized once.
> 
> Signed-off-by: Nam Cao <namcao@linutronix.de>

With or without the helper dropped, which can easily go on top at our leisure:

Acked-by: Sean Christopherson <seanjc@google.com>

On Mon, Oct 28, 2024, Nam Cao wrote:
> The hrtimer is initialized in the KVM_XEN_VCPU_SET_ATTR ioctl. That caused
> problem in the past, because the hrtimer can be initialized multiple times,
> which was fixed by commit af735db31285 ("KVM: x86/xen: Initialize Xen timer
> only once"). This commit avoids initializing the timer multiple times by
> checking the field 'function' of struct hrtimer to determine if it has
> already been initialized.
> 
> Instead of "abusing" the 'function' field, move the hrtimer initialization
> into kvm_xen_init_vcpu() so that it will only be initialized once.
> 
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
> Cc: Sean Christopherson <seanjc@google.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: x86@kernel.org
> Cc: kvm@vger.kernel.org
> ---
>  arch/x86/kvm/xen.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index 622fe24da910..c386fbe6b58d 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -1070,9 +1070,6 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
>  			break;
>  		}
>  
> -		if (!vcpu->arch.xen.timer.function)
> -			kvm_xen_init_timer(vcpu);
> -
>  		/* Stop the timer (if it's running) before changing the vector */
>  		kvm_xen_stop_timer(vcpu);
>  		vcpu->arch.xen.timer_virq = data->u.timer.port;
> @@ -2235,6 +2232,7 @@ void kvm_xen_init_vcpu(struct kvm_vcpu *vcpu)
>  	vcpu->arch.xen.poll_evtchn = 0;
>  
>  	timer_setup(&vcpu->arch.xen.poll_timer, cancel_evtchn_poll, 0);
> +	kvm_xen_init_timer(vcpu);

I vote for opportunistically dropping kvm_xen_init_timer() and open coding its
contents here.

If the intent is for subsystems to grab their relevant patches, I can fixup when
applying.

>  	kvm_gpc_init(&vcpu->arch.xen.runstate_cache, vcpu->kvm);
>  	kvm_gpc_init(&vcpu->arch.xen.runstate2_cache, vcpu->kvm);
> -- 
> 2.39.5
>

On Mon, Oct 28 2024 at 09:01, Sean Christopherson wrote:
> On Mon, Oct 28, 2024, Nam Cao wrote:
>> The hrtimer is initialized in the KVM_XEN_VCPU_SET_ATTR ioctl. That caused
>> problem in the past, because the hrtimer can be initialized multiple times,
>> which was fixed by commit af735db31285 ("KVM: x86/xen: Initialize Xen timer
>> only once"). This commit avoids initializing the timer multiple times by
>> checking the field 'function' of struct hrtimer to determine if it has
>> already been initialized.
>> 
>> Instead of "abusing" the 'function' field, move the hrtimer initialization
>> into kvm_xen_init_vcpu() so that it will only be initialized once.
>> 
>> Signed-off-by: Nam Cao <namcao@linutronix.de>
>> ---
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: x86@kernel.org
>> Cc: kvm@vger.kernel.org
>> ---
>>  arch/x86/kvm/xen.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>> 
>> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
>> index 622fe24da910..c386fbe6b58d 100644
>> --- a/arch/x86/kvm/xen.c
>> +++ b/arch/x86/kvm/xen.c
>> @@ -1070,9 +1070,6 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
>>  			break;
>>  		}
>>  
>> -		if (!vcpu->arch.xen.timer.function)
>> -			kvm_xen_init_timer(vcpu);
>> -
>>  		/* Stop the timer (if it's running) before changing the vector */
>>  		kvm_xen_stop_timer(vcpu);
>>  		vcpu->arch.xen.timer_virq = data->u.timer.port;
>> @@ -2235,6 +2232,7 @@ void kvm_xen_init_vcpu(struct kvm_vcpu *vcpu)
>>  	vcpu->arch.xen.poll_evtchn = 0;
>>  
>>  	timer_setup(&vcpu->arch.xen.poll_timer, cancel_evtchn_poll, 0);
>> +	kvm_xen_init_timer(vcpu);
>
> I vote for opportunistically dropping kvm_xen_init_timer() and open coding its
> contents here.

Makes sense.

> If the intent is for subsystems to grab their relevant patches, I can fixup when
> applying.

Ideally I can route it through my tree to avoid a full release delay as
the subsequent changes depend on this and the core hrtimer API changes.

Thanks,

        tglx