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 44A6E34CFDD for ; Mon, 2 Mar 2026 23:47:52 +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=1772495273; cv=none; b=sq0PdijmW2oemVuqdgOUXnTKJ/qLKndCtt2j4cuCNecA3oHZOJFZYPWKXIgRqOcNtPXJsUfyJd8Iobsz7X9AhcROaRL3ExdnHdq3ijD9PmQbCRHTxeTMGpx60NeEd0SYdDv6XehM0PcqDYcYKBHNheYnk+V8FkRKgAS2a1R4BmE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772495273; c=relaxed/simple; bh=gDKf8MkiXtX8fnJadcRrbA6hjhwRgw/jy+uZjd8WTLc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=gnN1wfi7w6+BIuPsgo4M9DoLNXmt+E1K96dcN8VTCrkuX6+cTuC1NmKt3wp/zeVb+zaiiiFcJ2xlHY46NnLNfc5+rIx8iHoS4Q0ADFgxj7VKFHzCIzbhwxdoUE0MAKfptO5PRNyhCi6oP7sv/MlEm8Jox/VyH+XQLHVOs/RX3r0= 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=gFsoPqaW; 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="gFsoPqaW" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae415b68b1so25122455ad.2 for ; Mon, 02 Mar 2026 15:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772495271; x=1773100071; 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=ZnHr5TCbnlFoOtgJ9sz2D7mEHmLlKpVEDOL01Ue7p/s=; b=gFsoPqaWygogohUAIUwCFgJb5/cTzcLtU+Tp4EGD4YQhypVkhgLpbzZ/BPBTvoGyfs tM1Dbrk0SZasXgWUbU9wDa4INwcl6vlZmv38IkNBJbo0chfRccET6J5WaYqK3abtPu7H BYIqIpx+rihYteHC0n7sIF+AAcaQLG8tIx2c2ov1t96Y7xx20yrQTjc0wBZgVjrwYD/4 i2UrCGnNMa/r7jG0YHCswLU9HObUyD6j+3DOCC0zI8yfdVsUH0ZuZOdT6+hAEQgRKToi /H7U+kTpxIeAPdskuwsr9YBf/2PzAdEWMxAwL7XnoV/3G62aCDfzSid5f8EzynZzUSZm aYwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772495271; x=1773100071; 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=ZnHr5TCbnlFoOtgJ9sz2D7mEHmLlKpVEDOL01Ue7p/s=; b=JYu/t3ATMu59c3tJttIWNjj7bBLNOgFFRmqvo77aDdmjrrVOKcPYRaJXHKSu2K1Ig3 6kFOFn2lzhM4uIIE/PJu7nBpo+OLsNd3Et7Z2ckRoVPHXaAwboMysKZJw9L7vghgVwL2 0dJN26SucR8Dml/Rozy41wUvzVDAZh+XacryJZP5ZKY/VoVutt6/AFAwb1pBVrivr1eV CqFiQaR1yMzbiBnP22ud/btBabAvsVZH9F3m9b05jmAPhjb8zdZnJFFQM8MMKQnss7tt OLffUMuYMzWpKyOjbrUoWoZ5ehvWq3KLdpIXUYlZX3Yg7Bdg84f1Ar4R6EgUdWu++KTc 283A== X-Forwarded-Encrypted: i=1; AJvYcCUECQBpDuivFsVqFRNcgNywOg3psA1Whgc836cW/1WuMoDmW0MOveLn+YGfmk+oKeqCbbuAdQYjxp4+8Hg=@vger.kernel.org X-Gm-Message-State: AOJu0Ywq3MajMzlZAbQRE23NuEtkeeSsbLugVOFd8NS5w7v2FRU2/Gs9 ixfktc7zEXsJLnoWtuyyYP8lGzYC9sSA2VCJMZ8UZ4Vd1gBVUSVUhmQGHJslJbVDRvPmYOJPrM3 HHotolA== X-Received: from plov20.prod.google.com ([2002:a17:902:8d94:b0:2ab:3ae7:5481]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ea10:b0:2ae:4f15:1ab6 with SMTP id d9443c01a7336-2ae4f15218fmr60122995ad.15.1772495271343; Mon, 02 Mar 2026 15:47:51 -0800 (PST) Date: Mon, 2 Mar 2026 15:47:49 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260227011306.3111731-1-yosry@kernel.org> <20260227011306.3111731-4-yosry@kernel.org> Message-ID: Subject: Re: [PATCH 3/3] KVM: x86: Check for injected exceptions before queuing a debug exception From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 02, 2026, Yosry Ahmed wrote: > On Mon, Mar 2, 2026 at 3:22=E2=80=AFPM Sean Christopherson wrote: > > > > On Fri, Feb 27, 2026, Yosry Ahmed wrote: > > > > > That being said, I hate nested_run_in_progress. It's too close to > > > > > nested_run_pending and I am pretty sure they will be mixed up. > > > > > > > > Agreed, though the fact that name is _too_ close means that, aside = from the > > > > potential for disaster (minor detail), it's accurate. > > > > > > > > One thought is to hide nested_run_in_progress beyond a KConfig, so = that attempts > > > > to use it for anything but the sanity check(s) would fail the build= . I don't > > > > really want to create yet another KVM_PROVE_xxx though, but unlike = KVM_PROVE_MMU, > > > > I think we want to this enabled in production. > > > > > > > > I'll chew on this a bit... > > > > > > Maybe (if we go this direction) name it very explicitly > > > warn_on_nested_exception if it's only intended to be used for the > > > sanity checks? > > > > It's not just about exceptions though. That's the case that has caused= a rash > > of recent problems, but the rule isn't specific to exceptions, it's ver= y broadly > > Thou Shalt Not Cancel VMRUN. > > > > I think that's where there's some disconnect. We can't make the nested= _run_pending > > warnings go away by adding more sanity checks, and I am dead set agains= t removing > > those warnings. > > > > Aha! Idea. What if we turn nested_run_pending into a u8, and use a ma= gic value > > of '2' to indicate that userspace gained control of the CPU since neste= d_run_pending > > was set, and then only WARN on nested_run_pending=3D=3D1? That way we = don't have to > > come up with a new name, and there's zero chance of nested_run_pending = and something > > like nested_run_in_progress getting out of sync. >=20 > Yeah this should work, the only thing I would change is using macros > instead of 1 and 2 for readability. I was "this" close to using a enum or #define, but I couldn't figure out a = clean solution to this code: vcpu->arch.nested_run_pending =3D !!(kvm_state->flags & KVM_STATE_NESTED_RUN_PENDING); as I didn't want to end up with effectively: if (true) x =3D 1; else x =3D 0; But thinking more on it, that code is inherently untrusuted, so it can be t= his: if (kvm_state->flags & KVM_STATE_NESTED_RUN_PENDING) vcpu->arch.nested_run_pending =3D KVM_NESTED_RUN_PENDING_UNTRUSTED; else vcpu->arch.nested_run_pending =3D 0; which is pretty much the same, but at least is a bit more than a convoluted= cast from a bool to an int. FWIW, I verified this makes the C reproducer happy.