linux-kernel - Re: [PATCH] KVM: x86:Cancel hrtimer in the process of saving PIT state to reduce the performance overhead caused by hrtimer during guest stop.

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

Message-ID: <Z9gl5dbTfZsUCJy-@google.com>
Date: Mon, 17 Mar 2025 06:38:45 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Liam Ni <liamni-oc@...oxin.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org, 
	pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, hpa@...or.com, LiamNi@...oxin.com, 
	CobeChen@...oxin.com, LouisQi@...oxin.com, EwanHai@...oxin.com, 
	FrankZhu@...oxin.com
Subject: Re: [PATCH] KVM: x86:Cancel hrtimer in the process of saving PIT
 state to reduce the performance overhead caused by hrtimer during guest stop.

On Mon, Mar 17, 2025, Liam Ni wrote:
> When using the dump-guest-memory command in QEMU to dump
> the virtual machine's memory,the virtual machine will be
> paused for a period of time.If the guest (i.e., UEFI) uses
> the PIT as the system clock,it will be observed that the
> HRTIMER used by the PIT continues to run during the guest
> stop process, imposing an additional burden on the system.
> Moreover, during the guest restart process,the previously
> established HRTIMER will be canceled,and the accumulated
> timer events will be flushed.However, before the old
> HRTIMER is canceled,the accumulated timer events
> will "surreptitiously" inject interrupts into the guest.
> 
> SO during the process of saving the KVM PIT state,
> the HRTIMER need to be canceled to reduce the performance overhead
> caused by HRTIMER during the guest stop process.
> 
> i.e. if guest
> 
> Signed-off-by: Liam Ni <liamni-oc@...oxin.com>
> ---
>  arch/x86/kvm/x86.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 045c61cc7e54..75355b315aca 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6405,6 +6405,8 @@ static int kvm_vm_ioctl_get_pit(struct kvm *kvm, struct kvm_pit_state *ps)
>  
>  	mutex_lock(&kps->lock);
>  	memcpy(ps, &kps->channels, sizeof(*ps));
> +	hrtimer_cancel(&kvm->arch.vpit->pit_state.timer);
> +	kthread_flush_work(&kvm->arch.vpit->expired);

KVM cannot assume userspace wants to stop the PIT when grabbing a snapshot.  It's
a significant ABI change, and not desirable in all cases.

>  	mutex_unlock(&kps->lock);
>  	return 0;
>  }
> @@ -6428,6 +6430,8 @@ static int kvm_vm_ioctl_get_pit2(struct kvm *kvm, struct kvm_pit_state2 *ps)
>  	memcpy(ps->channels, &kvm->arch.vpit->pit_state.channels,
>  		sizeof(ps->channels));
>  	ps->flags = kvm->arch.vpit->pit_state.flags;
> +	hrtimer_cancel(&kvm->arch.vpit->pit_state.timer);
> +	kthread_flush_work(&kvm->arch.vpit->expired);
>  	mutex_unlock(&kvm->arch.vpit->pit_state.lock);
>  	memset(&ps->reserved, 0, sizeof(ps->reserved));
>  	return 0;
> -- 
> 2.25.1
>