From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.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 3DDDD3C0624 for ; Tue, 26 May 2026 19:11:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779822699; cv=none; b=ToFtU22EGJPoaNKsEuxcqPyWdx70bxji0Aw2wsLdj0qO/qX8ePQUzNTXKxIlmLzA2Nj0lA1GG+ArSm543PdSoqVxVrTSphvYLtB5uEOkgYhKJItbc2XTFKcLoAvZTZ1OukHcnAg+ZbTrg8x3I01g0+GJCR3cgCEGTVooXgiB4gw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779822699; c=relaxed/simple; bh=r0B3/LXiCCefp1GjqQcNi43nrCqy4jhnGJo1iHggQ70=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=u+JDjVYsQ+Tw3wuMND+BcNloFpoTceQMBV+3JSY4p0WMlWykX7rWPMQ5MV/sW2MDnKTt5u4I1MRnXBM1RYxaVnrIH0gbdaPNCkye0dDWt3Ym4dfZ3sAV0dhnoY6jUfDZ5LU+ug6DE3cesQiy7HSa81xy3LsW6ze4mnLEo5rWDOQ= 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=Rd+PDZzc; arc=none smtp.client-ip=209.85.215.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="Rd+PDZzc" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c82c935e048so6804809a12.0 for ; Tue, 26 May 2026 12:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779822698; x=1780427498; 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=H7aWUpmpx5OZU/6ppMEyWSa6e+OFoaoQGmjbVgY2GCQ=; b=Rd+PDZzcPLkAo9EkxDqOuiCVP89Q1wc4f06Uc4R27b0hE4hMLMeXg0CR4OVCMpaOnq h206WgLkzcyYvrwfY2+lMWEc0w3r9ve4EdVKatX3T1qFx8TB0gbHkL6DUFwc++PFOB4K 0j2jA9J14F76FsiGS6nGGbaA/EGP1eATyh3V3fGbtc1SbizeCcJ34HA8pE252HeXG5WN V6+N4yjBWe6OSMFkRgJSSlpdjH41XAONL92xlUhJ6YwR9EkcOaWHaDdZQZ9W+Jqgw3Ex ON274IFbln/zJXAHqE9VN18clN5YJFLMEyIP4ErLUx3uf06TgI+hjwxOoyBo7E4a1IdH ELlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779822698; x=1780427498; 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=H7aWUpmpx5OZU/6ppMEyWSa6e+OFoaoQGmjbVgY2GCQ=; b=fFpaqXtDXXIzcQqr+2DunPRggHenxI3YxpaRU9MUACLIIzlKYxZQkDtdLdUI9EZbee szI0FM3N2PXabuCNPo98ojOL3VpSPG09l/Bu5q6KktlOGImuIce8tlCAWytCRYNkzMme 6mftW3zukJ7sdiiQ1mZ03hscgJSVCXYrAmZbNiKw76RqhMY7SnLNezjrpNw/BmrtD8UX FUr51bW8ygDu+lfUNMd2xW3eH+qfx3krp3qg7N9QoJFpkkjvNra8DF9aNRZ4W/iFRGU+ O4fu5lbakbvDGFdMo/aCE6NZ5hFKE9zII9nQWoIjJaMOxjksDeR0k5ZefH4EE8huTOld p0HQ== X-Forwarded-Encrypted: i=1; AFNElJ8VMihAeQQ3JTWqApUil/Ju8rcQnMMUyxlyL0s1C97MkxjqlnH+DGfeFnFhnMBGCTAgsoj9JKAmxhfrVrQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzJQkNDt7djSY1fEOE4XF31Uu/aJWrkH9rJL0wgUFy+xDWXQgE6 btT5vKRbAPrKfC/uT5SP9d1xo814Fugci0OIUMv4+4cOEUOXcnVbSvqkPjyC4b6k6cNKrt5Qqtm GNNGYHg== X-Received: from pgbbw24.prod.google.com ([2002:a05:6a02:498:b0:c79:3224:837d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7283:b0:3a2:f05a:795e with SMTP id adf61e73a8af0-3b307bc9d78mr19907560637.3.1779822697331; Tue, 26 May 2026 12:11:37 -0700 (PDT) Date: Tue, 26 May 2026 12:11:36 -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: <20260506015733.1671124-1-yosry@kernel.org> <20260506015733.1671124-2-yosry@kernel.org> Message-ID: Subject: Re: [PATCH v6 01/16] KVM: nSVM: Stop leaking single-stepping on VMRUN into L2 From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , Jim Mattson , Dapeng Mi , Sandipan Das , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, May 22, 2026, Yosry Ahmed wrote: > On Fri, May 22, 2026 at 4:45=E2=80=AFPM Yosry Ahmed wr= ote: > > > > On Fri, May 22, 2026 at 4:10=E2=80=AFPM Sean Christopherson wrote: > > > > > > On Wed, May 06, 2026, Yosry Ahmed wrote: > > > > According to the APM, TF on VMRUN causes a #DB after VMRUN complete= s on > > > > the _host_ side. However, KVM injects a #DB in L2 context instead (= or > > > > exits to userspace if KVM_GUESTDBG_SINGLESTEP is set) in > > > > kvm_skip_emulated_instruction(). > > > > > > > > Introduce __kvm_skip_emulated_instruction(), > > > > > > Eh, just make svm_skip_emulated_instruction() visible via svm.h and c= all that > > > directly. No need to bring SVM's mess into common KVM. > > > > Yeah I thought about doing that. The only reason I was hesitant is > > that if [__]kvm_skip_emulated_instruction(), >=20 > if [__]kvm_skip_emulated_instruction() gains new logic* Well, __kvm_skip_emulated_instruction() can't gain new logic if it doesn't = exist, which is why I want to avoid it. IMO, it's _more_ likely that we'd add cod= e to __kvm_skip_emulated_instruction() that breaks the obscure VMRUN behavior. And if we add logic to kvm_skip_emulated_instruction(), it's seems like a f= orgone conclusion that we'll have to analyzing VMRUN to see what the "right" behav= ior is. > > handling it here might be missed. Also, there's only one direct caller = of > > svm/vmx_skip_emulated_instruction() (and it's TASK_SWITCH interception,= who > > cares). handle_exception_nmi() also calls it for INT1, though that code is broken (= the INT1 should count as an instruction). > > So I think it's more consistent and future proof to refactor > > kvm_skip_emulated_instruction() instead. I actually think the task switch case is the perfect argument for using svm_skip_emulated_instruction() directly. The only flows crazy enough to w= arrant bypassing normal instruction skipping behavior are legacy task switches and= VMRUN. Sounds about right to me :-)