From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) (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 897B451DAE9 for ; Thu, 15 Oct 2026 13:58:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792072736; cv=none; b=BdGCfjzPo+i3L6OKSeR71no1nubRFJgYse8K0zRAF1JT5f7O4o4es94AKDLbY2CpaAMYnYnBuwvfcT4ZDG10/O/4b/mb2e+BbgHtfmQhRL/wV+jGeifUQNE/NCx5Rj/0CshMNPdfqyurc2ToBYSlkkwhjvQhNbhgZrxYw7Odw1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792072736; c=relaxed/simple; bh=Fmr8PvRAaAoeaJUzhHvHl4m0oLOfVqb5pwowBeNSOdg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=u7Uh3oxyStgmtvtqn7jmNiwi+de/8WnH6w5NKToxQ25ecEID5rJaH1mi9OD3yfFUvkZQOTQifEnoH6Z1MFU7v6O1J6/2F8pSFUm5IMIt6Fww0nRuq0pbFOWG7hWaUctQSrN0t0PiJO/FmxbAMXXoPYUxzTgJIMIlnje1ReacBQc= 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=HlCBtEUq; arc=none smtp.client-ip=209.85.214.197 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="HlCBtEUq" Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2e61a48d5b7so50092225ad.1 for ; Thu, 15 Oct 2026 06:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1792072735; x=1792677535; darn=lists.linux.dev; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=uMSSECwkd6GBn6Q0rd3u20QgElhwSrNALm0yFALuhrI=; b=HlCBtEUqgkgOBy3JczG16ChfuHw9XkeYoXV/Y8HtTmmO2C/I8EhhBXFP6SIuNLtb+R AEz9vWnCD6mhtaEcprb+UPMkdxhUxmtQ10DbG/F199L1ZrgTYrWOaqjn1kaUcqxC2kej 0xqZ6faPYmFWsG+GD479YzYs95x+gCfZokc2FMvmv6sxIGoqe1xtzYQQDE3thWmi+FTH +Ts+1mliWQCbXxIXStUnks0CHD48/aGJX+dCDdf7EE6h1rb06yc+l/ABMK4Hr8Igdtnz SpJ9ed9BkhvLC7Y0TlWQvzORQHL9g2qC3UVKtb8qh6+/bIqMqD4ewImwDlpZggXRZEhl AZrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792072735; x=1792677535; h=content-type: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:content-type; bh=uMSSECwkd6GBn6Q0rd3u20QgElhwSrNALm0yFALuhrI=; b=jgDqJ95wmSbjBkAjEBc+KcqY+toLEs+sDEwbr4XrpizJtjglyH1U2+J5iecep+LwfI N0Tq7x5sErbkohqa1ZJop1jQR1D0cs6PUQwAQiXCy0u5lH4tBhBMbrftaAjDs96i3V8i nFayXl+QceKEj7Iw3VNtvaYZIDf43ZKTrSZNk+K32os+Y1BPNaxfqGp1plok5xJrKLvl bLaVwrPb8eW/YVesCuilljE17c/Ji9V8Bls48B6r5KgRg0yVRsUfvwW/7AvyXmW2mofT juX+gm0ijxwe66XvkoaPjlQg2EY14fijy18VqvotBtvAJs57bEWV4UQlTSwjAxRwwMht yX7w== X-Forwarded-Encrypted: i=1; AKwUvBynKPFOVk01zV6e4LtlySpJxkCm+B4mf+F8YBfMBGXWu6maF2ULpRht66tVBAjtsTImVydBOrxJOZ3X@lists.linux.dev X-Gm-Message-State: AFq9FYK+9Htminqu/zB4LOvCoEWWZwFrcYbcuGeh/aZMAr0PuKI/IA0M TuEorjkWTSADIiKpa5e5wOxU7QRP4gAL30MDMbBiEcpoV1+edcyvJtzg9LgsFpv7Kv2NIVZKGG3 yklhj/w== X-Received: from pllq21.prod.google.com ([2002:a17:902:7895:b0:2e2:c8c0:e8eb]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2348:b0:2e9:3295:11d1 with SMTP id d9443c01a7336-2e97758f920mr460105ad.39.1792072733289; Thu, 15 Oct 2026 06:58:53 -0700 (PDT) Date: Thu, 15 Oct 2026 06:58:52 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260930001127.3170009-1-seanjc@google.com> <20260930001127.3170009-3-seanjc@google.com> Message-ID: Subject: Re: [PATCH v2 2/3] KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled EPT violation From: Sean Christopherson To: Yan Zhao Cc: Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe , Dave Hansen , kvm@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, James Houghton , Xiaoyao Li , Binbin Wu , Ackerley Tng , Vishal Annapurve , Sashiko Bot Content-Type: text/plain; charset="us-ascii" On Sat, Oct 10, 2026, Yan Zhao wrote: > On Tue, Sep 29, 2026 at 05:11:26PM -0700, Sean Christopherson wrote: > > Exit to userspace with KVM_EXIT_SHUTDOWN instead of returning -EIO from > > KVM_RUN if KVM encounters an EPT Violation due to a guest access to a > > pending page. Returning -EIO implies KVM is buggy, and most VMMs will > > respond by completely terminating the VM, versus rebooting the VM in > > response to KVM_EXIT_SHUTDOWN. I.e. give the VMM the option of trying to > > keep the VM (from the end user's perspective) alive. > > > > Ideally, KVM would probably exit with KVM_EXIT_MEMORY_FAULT, but KVM would > > need to extend run->memory_fault so that userspace knows the fault can't be > > handled. This scenario specifically occurs when the guest has deliberately > > disabled #VEs on unaccepted memory for security purposes, i.e. the guest > > literally disabled the mechanism that tells it it screwed up. But, because > > this is fatal, and the whole point is to NOT try to fixup the fault, > > jumping through hoops to return MEMORY_FAULT instead of SHUTDOWN doesn't > > make a whole lot of sense. > > > > Don't bother bouncing through KVM_REQ_TRIPLE_FAULT as > > tdx_handle_ept_violation() is a top-level exit handler, i.e. there is no > > need to worry about failing to actually exit to userspace. > > > > Fixes: e6a85781f783 ("KVM: TDX: Detect unexpected SEPT violations due to pending SPTEs") > > Cc: stable@vger.kernel.org > > Cc: James Houghton > > Cc: Xiaoyao Li > > Cc: Rick Edgecombe > > Cc: Yan Zhao > > Cc: Binbin Wu > > Cc: Ackerley Tng > > Cc: Vishal Annapurve > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kvm/vmx/tdx.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c > > index 29d4751f37fb..e3723f1222fc 100644 > > --- a/arch/x86/kvm/vmx/tdx.c > > +++ b/arch/x86/kvm/vmx/tdx.c > > @@ -1939,8 +1939,8 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu) > > if (tdx_is_sept_violation_unexpected_pending(vcpu)) { > > pr_warn("Guest access before accepting 0x%llx on vCPU %d\n", > > gpa, vcpu->vcpu_id); > > - kvm_vm_dead(vcpu->kvm); > > - return -EIO; > > + kvm_prepare_shutdown_exit(vcpu); > Would it be better to exit with the reason KVM_EXIT_SYSTEM_EVENT and type > KVM_SYSTEM_EVENT_SHUTDOWN or KVM_SYSTEM_EVENT_TDX_FATAL? No. KVM_SYSTEM_EVENT_SHUTDOWN is an explicit call from the guest to do a clean shutdown (used by arm64 and RISC-V). KVM_SYSTEM_EVENT_TDX_FATAL similarly exists to relay explicit calls from the guest. Ditto for KVM_SYSTEM_EVENT_CRASH and KVM_SYSTEM_EVENT_SEV_TERM (which obviously is a poor fit for TDX, just pointing out that it's another guest-initiated event). KVM_EXIT_SHUTDOWN isn't a perfect fit, but IMO it's the closest approximation, e.g. it's a rough equivalent of what happens if a #VE couldn't be handled because the stack is invalid. And more importantly, because we're retroactively fixing code, KVM_EXIT_SHUTDOWN has the best chance of being handled appropriately by all VMMs. > By defining a specific flag (e.g., KVM_SYSTEM_EVENT_FLAG_TDX_UNEXPECTED_PENDING), > we can stuff necessary info like gpa, vcpu->vcpu_id into data, so both pr_warn() > and pr_warn_ratelimited() can be dropped. Well, IMO, the printk can be dropped no matter what. :-) But I don't care _that_ much so I'm ok keeping the ratelimited version. vcpu_id is redundant, the exit is tied to a specific vCPU. And as I said elsewhere, practically speaking the GPA is all but guaranteed to be useless outside of interactive debug sessions.