From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.zhaoxin.com (MX1.ZHAOXIN.COM [210.0.225.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF62D224AFB for ; Mon, 7 Apr 2025 07:38:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.0.225.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744011502; cv=none; b=pV9V2oxRfaZCs6hVfDmHUp1R/tQJPqlazS4x/XHsyNAOPK7m/dELeVnVIdRbp+ZEURCHeaLv9FGMGpFdVetnQ/N/W9O4ZT7GhxewMsttkqI2gQ8MaSQSrpoUt7PuXQ0qaeEPNOblpMCE38rxF8fZ9GSH3JBuK3UsOm7zYhVS1Uw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744011502; c=relaxed/simple; bh=DuK3bifKObUj/1hjDahLrFJvEo4z68yicijyl+kid9k=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=N7GTvI7tdIhEEOIIHDVkN3cd0JE0qT1RqXz8FJhBCfB2hpKcRnx9VrGW+ekDK7CPI4SV0BHxNOeLsKzAIb9ZGTV5Uo/rPhhg13zOl0oBAOuFeBLaa+yQrG710Cys8cLPYvTdrs8XD6qYK/Ok3PPv+WLCBNPkezGzIilIwNsB8ZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=zhaoxin.com; spf=pass smtp.mailfrom=zhaoxin.com; arc=none smtp.client-ip=210.0.225.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=zhaoxin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zhaoxin.com X-ASG-Debug-ID: 1744011490-086e2365b944450001-xx1T2L Received: from ZXSHMBX1.zhaoxin.com (ZXSHMBX1.zhaoxin.com [10.28.252.163]) by mx1.zhaoxin.com with ESMTP id kLJek5uXD4GYIZIg (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 07 Apr 2025 15:38:10 +0800 (CST) X-Barracuda-Envelope-From: LiamNi-oc@zhaoxin.com X-Barracuda-RBL-Trusted-Forwarder: 10.28.252.163 Received: from ZXSHMBX3.zhaoxin.com (10.28.252.165) by ZXSHMBX1.zhaoxin.com (10.28.252.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Mon, 7 Apr 2025 15:38:10 +0800 Received: from ZXSHMBX3.zhaoxin.com ([fe80::8cc5:5bc6:24ec:65f2]) by ZXSHMBX3.zhaoxin.com ([fe80::8cc5:5bc6:24ec:65f2%6]) with mapi id 15.01.2507.044; Mon, 7 Apr 2025 15:38:09 +0800 X-Barracuda-RBL-Trusted-Forwarder: 10.28.252.163 Received: from [10.28.66.46] (10.28.66.46) by ZXBJMBX02.zhaoxin.com (10.29.252.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Mon, 7 Apr 2025 10:19:32 +0800 Message-ID: Date: Mon, 7 Apr 2025 10:19:31 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird 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. To: Sean Christopherson X-ASG-Orig-Subj: Re: [PATCH] KVM: x86:Cancel hrtimer in the process of saving PIT state to reduce the performance overhead caused by hrtimer during guest stop. CC: , , , , , , , , , , , , , References: <20250317091917.72477-1-liamni-oc@zhaoxin.com> <676ed22f-9c3f-4013-99d8-37c4c73bb9ac@zhaoxin.com> From: LiamNioc In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: ZXSHCAS1.zhaoxin.com (10.28.252.161) To ZXBJMBX02.zhaoxin.com (10.29.252.6) X-Moderation-Data: 4/7/2025 3:38:08 PM X-Barracuda-Connect: ZXSHMBX1.zhaoxin.com[10.28.252.163] X-Barracuda-Start-Time: 1744011490 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.28.252.35:4443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at zhaoxin.com X-Barracuda-Scan-Msg-Size: 2798 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.139610 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 2025/4/4 22:48, Sean Christopherson wrote: >=20 >=20 > [=E8=BF=99=E5=B0=81=E9=82=AE=E4=BB=B6=E6=9D=A5=E8=87=AA=E5=A4=96=E9=83=A8= =E5=8F=91=E4=BB=B6=E4=BA=BA =E8=B0=A8=E9=98=B2=E9=A3=8E=E9=99=A9] >=20 > On Tue, Mar 25, 2025, LiamNioc wrote: >> On 2025/3/17 21:38, Sean Christopherson wrote: >>> 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 >>>> --- >>>> 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 snaps= hot. It's >>> a significant ABI change, and not desirable in all cases. >> >> When VM Pause, all devices of the virtual machine are frozen, so the PIT >> freeze only saves the PIT device status, but does not cancel HRTIMER, bu= t >> chooses to cancel HRTIMER when VM resumes and refresh the pending task. >> According to my observation, before refreshing the pending task, these >> pending tasks will secretly inject interrupts into the guest. >> >> So do we need to cancel the HRTIMER when VM pause=EF=BC=9F >=20 > The problem is that KVM has no real concept of pausing a VM. There are a= variety > of hacky hooks here and there, but no KVM-wide notion of "pause". >=20 > For this case, after getting PIT state, you should be able to use KVM_SET= _PIT2 to > set the mode of channel[0] to 0xff, which call destroy_pit_timer() via > pit_load_count(). Got it. so i need to modify the behavior of QEMU's code.