From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 3A5352765F5 for ; Mon, 15 Jun 2026 17:26:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781544392; cv=none; b=F9TCKB76yuZWWJbxRX9Pt5RLeODKt9DUXZ/GdupRHg+4kXoT7Aob3J/VnTv1bCCLIUWsEmalduTI6LUAY149wOdPwshP3jecwHJKf9kNKJQSOtFYbqxsNiExfuH0R+FoedBsfT/qqImtEOykZi+/zUZgPx5puB2V88zfRwOE0Ac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781544392; c=relaxed/simple; bh=n7j2xuSEoLWXT4WWaLtAQaJv1XDcEbEbTdrNUD+gpXY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=L8aV9mtuHZ0Gps/ehlWg3025rK+X00RcNScwYCw+Y0DJ3JI8vCMHv2hbC5IZ4OdmAWBGYEeY/6FcYCWW14ToHvHZ/1WOshBFwQ8R08hfQcl3mc+QAw3BrDfcmbFPTLnbhKkvDH7KdTXPqufXWz678usRBH6GhO/pSnYSxnjb66M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=DBpCAU04; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="DBpCAU04" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2c0c20f7581so37094645ad.0 for ; Mon, 15 Jun 2026 10:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781544391; x=1782149191; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=G1YFLp6Nv/x/zFzqR11/t+OBKepAibObBP++vs6jo78=; b=DBpCAU04DoMMxjlZnlI5snzRZktD4s5qIV7uy4qGs8OkHrCWrQhyhGFMCyuLwp6Cds fOgphHIgPtPIGTA3AasG+WMhT2JYN2TosFinG2dBRD/3/o35FHjp+8yxKKQiXIBbmGOr fP2dRW7O6sGdvvDe+PVTGk+h4XYmf/bvMZizj4aAf1VRcm25Ye28Y3i+FRT56lDyvj/1 djHTlixpJs9wAEciOlPAhG5w5zW1eMllGbBdkA6vTfWVBsUoQOohNL87OaBbvW/aNPKW /um6jJLvHKEDSPMSScQqfoLFrl//OE288H4grwCgfrpE+7DLBB498vFqRd0No5QEgNUx d/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781544391; x=1782149191; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=G1YFLp6Nv/x/zFzqR11/t+OBKepAibObBP++vs6jo78=; b=hs1VZenKgOeM8b5J37J3WmhKMQ0uXKRpweIfyHTGw5wxTgcw6gEGQ48a/ctMmebK3K 1rMoFJ+TgI3wqPv4gFLu4kFsSnBmubiW+zvYsQztTMnkKGjN/yGv7Yn5CZpF0mImn+xW KNT4C93YB008JX0Tf5zILCpM2AzZiLhgNKi2x3G9hGxXG+v8Fib0hlAc6jjrsFjMtuRa prQRSKeVx5BND5zlO+6MTuhcscjvkz4yqqHl/u/5Wp3CtluLEN6VbVZNQ1fzdacJggKR seXqIsdgcZSXqn1uHrC/2oeVk6H+EjBjqK1oy0lzCnA3F97uhvVLZ5ygOZx1XpkpyfQn kbcA== X-Forwarded-Encrypted: i=1; AFNElJ+RF/LC8DXl8ndRpp75WdmQjAWh6kZXGB90iqDXcpNrIJLjrxM9gYwDsFCIAQICYpYvr0E4JUHVBOKDGQQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw/T+Pq0OU1DEHyD7Q0TzS/EyEm4I6AZtGroTd0OCI1jXSjEAIG h3rks7agLfmtixV3iA0VUTMDg6s3/gp55AGnbHIBZT1qnDTLHxuOyLKGBXSCUISUgAHSnx5RKZQ 2EVoTqA== X-Received: from plbv4.prod.google.com ([2002:a17:903:44c4:b0:2bd:9574:2958]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:cf08:b0:2c2:cf20:213 with SMTP id d9443c01a7336-2c69a1b55d7mr1652265ad.29.1781544390381; Mon, 15 Jun 2026 10:26:30 -0700 (PDT) Date: Mon, 15 Jun 2026 10:26:29 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260613000329.732085-1-seanjc@google.com> <20260613000329.732085-27-seanjc@google.com> Message-ID: Subject: Re: [PATCH v4 26/30] KVM: x86: Don't treat interrupts as allowed just because a nested run is pending From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , Vitaly Kuznetsov , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kai Huang Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2026, Yosry Ahmed wrote: > On Fri, Jun 12, 2026 at 5:04=E2=80=AFPM Sean Christopherson wrote: > > > > When querying whether or not interrupts (IRQs) are allowed, check for a > > pending nested run _after_ checking whether or not interrupts are block= ed. > > If L1 is running L2 _without_ nested_exit_on_intr(), i.e. if L1 IRQs ca= n > > be blocked while running L2, and interrupts will indeed be blocked once= the > > nested VM-Enter to L2 is completed, then KVM should treat interrupts as= not > > being allowed. > > > > For injection, this avoids an unnecessary (forced) VM-Exit, as KVM can > > immediately request an IRQ window, instead of forcing an exit and _then= _ > > requesting an IRQ window (because after the forced exit, KVM will see t= hat > > interrupts are blocked). > > > > For non-injection usage, only kvm_vcpu_ready_for_interrupt_injection() = is > > affected in practice. kvm_vcpu_has_events() is unreachable when a nest= ed > > run is pending, as KVM clears nested_run_pending prior to calling > > kvm_emulate_halt_noskip() when putting L2 into HLT via GUEST_ACTIVITY_H= LT, > > and SVM has no equivalent to GUEST_ACTIVITY_STATE. I.e. the vCPU will > > always be runnable if a nested run is pending, and thus > > kvm_arch_vcpu_runnable() =3D> kvm_vcpu_has_events() is effectively dead= code, > > as is __kvm_emulate_halt() =3D> kvm_vcpu_has_events(). Oh, and TDX doe= sn't > > support nested VMX. Similarly, kvm_can_do_async_pf() is unreachable as > > KVM shouldn't be faulting in memory with a pending nested VM-Enter. > > > > As for kvm_vcpu_ready_for_interrupt_injection(), incorrectly treating > > interrupts as being allowed could result in KVM prematurely exiting to > > userspace to accept an ExtINT. >=20 > "incorrectly treating interrupts as being allowed" is the status quo, > that this patch fixes, not sth this patch introduces -- right? Right. > The changelog reads like for the non-injection case this change might > not be the right thing to do, but I don't think this is the case? I > assume returning false from > kvm_vcpu_ready_for_interrupt_injection() and kvm_vcpu_has_events() if > L1's interrupts are blocked while L2 is running is the right thing to > do? Yes. > The code makes sense to me but I am trying to make sense of the changelog= . What part (parts?) is confusing? Honest question. I'm trying to reword th= e changelog to make it "better", but I'm failing miserable because I don't kn= ow what's wrong :-)