From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1C812A1AA for ; Wed, 22 Oct 2025 15:01:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761145289; cv=none; b=fAw8+j1DMn1hvuOGelMrJtmgXMaxQlM7M2X3PClW0kC7LXIbmtt1tEkiNjmmn2CyUFjSYbEDcFaKrBFLTy4CCeFWWS8+raQr4kXPRZE5vUmSGtZLGp61RR8EbMRWDxN8+8e9Gv1KmEi1LOKJIZJMtURIo/TSEclSu3X5eDoR3hU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761145289; c=relaxed/simple; bh=mEnMsksYyQt5aEAUXre8DN1ukr+yNhOXBpn8bpnEj/Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=MJejw08psD+ennWp7F1gEJpGDB0mVWgdoEaVDO3lZcLr6+VeFLNA9Fvx4+LC7TptqDfJceHr4erab60z/ByzbB1jPED8vvu2ZW/EAOXD5AVFlI67jHuyx6WIeJcX2yP3Zl4y3OiHedApc3USbYbRcVxDIaIoohIqPTm+8gj0+hQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nWLVuh8e; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nWLVuh8e" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-7810289cd4bso6672261b3a.2 for ; Wed, 22 Oct 2025 08:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761145286; x=1761750086; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=BKHUhsWN+6UVYafe0YQA/a4l4Z1s6RddT15lV1Hyq7s=; b=nWLVuh8eAma3y9WWnEjtJVbN3aS0mmzfH+9zArkBFs5BH/PTFZxANxPc6OnWHLTS5M 6k15KBVvAbzSzgyGDtk/SJTh8EyHjcGhwG6oHhwvVT32IJFRsIM8bpwFzrqxB58pHp/8 8mpLuSOeP8n2Qw1MAVSd7AnIBWJw1nzSPjyRXqDqhAkcu75Kmz0H3wcHEg0x/NjFdWlU QFlDG/mcMchcAJ20gXWvZ4+haxmSyfRqqayeqoUkqwAeSCV93G/NmvQQZgaXLfOcltKL 59jdNdy9sfN1+sNvgjyZnwM4n/+UuihyI9mqkMuhiReYZLCsib7Ep2VNkm/gEDP3CV38 Uo8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761145286; x=1761750086; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BKHUhsWN+6UVYafe0YQA/a4l4Z1s6RddT15lV1Hyq7s=; b=eXt6xSgkDSovsI2hYh71qrVHwwMkfSYeZ3J2QyhPFdkrny0eHrG8l5oChIthZ5Rkoq gNmmatSB5cN6LNovUkSaJLPpTb1knGB0JpLC9pavSLNHq2oA6A3J0/+sZ5WPW9/rQakW OZq3UqUfFU6i2akrjQ/zSURO20k8SPCF1KRZrjGyy1eQAJ8BZyUvwKqrzklQWjKLu0K9 HnvvtB8DuWq0uG3Q5q5/jQjzTXyX1NBcjv0kTpMY8SrS276VUZBBEe/kSrZd227JJZdR 1Ls9wjz22vje+gKmSCfXFMHujRSrN7+FKdADByXG4yuLxV4ol8H0WW3iVsye9C8CAFsn UA2Q== X-Forwarded-Encrypted: i=1; AJvYcCVyHbiMOZO6ryYb2t8rxqonIhmNzGp0rmoe99jqtMESTT793/Rvs08s3XU2yW1KnNqMbJt/PE9z+scWTn0=@vger.kernel.org X-Gm-Message-State: AOJu0YxZxcJT41gGUW2i4gjv7NVRI02NWULQLIgSjgmvCUp4Z/eREoBR uB6jgGqZoFWydlry4uBbcQGtZkJ0AgA1r3XCxL/JXGfYfEMfjUD9sTX4 X-Gm-Gg: ASbGncu/+MvErkTlH8D56LAxTGOdiyIrdAnZL3Xy8CTEIOH0TqhPXFeud89U3lJxgKb QXcwCFV2CNxBIt8Et/uyf+msqSr98hnYJ5srW+GddxF8vtWO/la70OtUHGsdAwL6tDcKRKuMiye 7/+g3WO5IYVZzcNKn3/QPXeDhacohtJ/SJl24BK9VtSKF5PzSooHrE9RleBENPPY0hWK7vM/ZK8 i+tybAFbPIO0Gpm9Cbjj9ozU9gL4dHrqXYLOiektMrmeWJ81zteOn96+BlKLnpfh/LT+le692tL OmBS/AbefJ5/g/YCAs4M2Fz+RbAqzls3zW5HtjQq/Si7+D2hfTYEoEhpWmjR3nKAgvFSAG4l7ZY SraFTJ0/XgZRHQrZ+Yj6pa5Ic5zp1nTZG+mwxZnnSpwAr6NbfuuJ71TCjSU5kMSpV/cszcIjQl5 sbRihf7pdYjpcWkkuPAgEYvHlnVgNv3uVDMNTIdknf5KHRTnU= X-Google-Smtp-Source: AGHT+IHmIj5wlg+sqbx3TBr4eoLGV97MO266v8/FfvoVdqDwg7vTEnHrGPmGrUsibDIN5GLsYR2TBw== X-Received: by 2002:a05:6300:210a:b0:32d:a476:7075 with SMTP id adf61e73a8af0-334a856e51amr28088437637.23.1761145286156; Wed, 22 Oct 2025 08:01:26 -0700 (PDT) Received: from localhost.localdomain ([2408:80e0:41fc:0:8685:174d:2a07:e639]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-33e3125a3afsm1973624a91.6.2025.10.22.08.01.18 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 22 Oct 2025 08:01:25 -0700 (PDT) From: fuqiang wang To: Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Maxim Levitsky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: fuqiang wang , yu chen <33988979@163.com>, dongxu zhang Subject: [PATCH v3 0/2] KVM: x86: fix some kvm period timer BUG Date: Wed, 22 Oct 2025 23:00:53 +0800 Message-ID: <20251022150055.2531-1-fuqiang.wng@gmail.com> X-Mailer: git-send-email 2.47.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The following two patches fix some bugs in the x86 KVM periodic timer. ======= patch 1 ======= The first patch fixes a problem where, if the next period has already expired, e.g. due to the period being smaller than the delay in processing the timer, the hv timer will switch to the software timer and never switch back. The reproduction steps and patch verification results at link [1]. ======= patch 2 ======= The second patch fixes an issue where, if the first patch has not been applied, resuming a virtual machine after it has been suspended for a long time may trigger a hard lockup. Link [2] also talks about this issue. Link [2] also talks about this issue, but I don't think it can actually reproduce the problem. Because of commit [3], as long as the KVM timer is running, target_expiration will keep catching up to now (unless every single delay from timer virtualization is longer than the period, which is a pretty extreme case). Also, patch 2 is based on the changes in link [2], but with some differences: In link [2], target_expiration is updated to "now - period", and I'm not sure why it doesn't just catch up to now-maybe I'm missing something? In patch 2, I tentatively set target_expiration to catch up to now. The reproduction steps and patch verification results at link [4]. ============================================================= other questions -- Should the two patches be merged into one? ============================================================= If we end up making target_expiration catch up to now, patch 1 and patch 2 could probably be combined, since we wouldn't need the delta > 0 check anymore. But keeping them separate helps clearly show the two different problems we're fixing. However, the hardlockup issue only occurs when patch 1 is not merged, which leads to the commit message for the second patch repeatedly mentioning "...previous patch is merged". I'm not sure if this is appropriate, so I would like to hear your suggestions. [1]: https://github.com/cai-fuqiang/kernel_test/tree/master/period_timer_test [2]: https://lore.kernel.org/kvm/YgahsSubOgFtyorl@fuller.cnet/ [3]: d8f2f498d9ed ("x86/kvm: fix LAPIC timer drift when guest uses periodic mode") [4]: https://github.com/cai-fuqiang/md/tree/master/case/intel_kvm_period_timer Changes in v3: - Fix: advanced SW timer (hrtimer) expiration does not catch up to current time. - optimize the commit message of patch 2 - link to v2: https://lore.kernel.org/all/20251021154052.17132-1-fuqiang.wng@gmail.com/ Changes in v2: - Added a bugfix for hardlockup in v2 - link to v1: https://lore.kernel.org/all/20251013125117.87739-1-fuqiang.wng@gmail.com/ fuqiang wang (2): avoid hv timer fallback to sw timer if delay exceeds period fix hardlockup when waking VM after long suspend arch/x86/kvm/lapic.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) -- 2.47.0