linux-kernel - Re: [PATCH 04/21] KVM: x86/xen: Initialize hrtimer in kvm_xen_init

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zx-1ahdKLH3o2MHj@google.com>
Date: Mon, 28 Oct 2024 09:01:46 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Nam Cao <namcao@...utronix.de>
Cc: Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>, Kees Cook <kees@...nel.org>, 
	linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>, x86@...nel.org, 
	kvm@...r.kernel.org
Subject: Re: [PATCH 04/21] KVM: x86/xen: Initialize hrtimer in kvm_xen_init_vcpu()

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@...utronix.de>
> ---
> Cc: Sean Christopherson <seanjc@...gle.com>
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: x86@...nel.org
> Cc: kvm@...r.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
>