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: <87iktb27ms.ffs@tglx>
Date: Mon, 28 Oct 2024 23:19:07 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Sean Christopherson <seanjc@...gle.com>, Nam Cao <namcao@...utronix.de>
Cc: Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker
 <frederic@...nel.org>, 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 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@...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.

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