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 8A4713D170B for ; Tue, 10 Mar 2026 17:17: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=1773163074; cv=none; b=KtNfMe4FkXgjAMa25t9RLOg5YdSMENJDD9XGXD83xq387Q+3/Q+FJG+qxhwYGCUKho745c7rYOCfhRzR0KolgdCc9m8ckSY4H9g5UlTt69WJ1iPWWrpdCXam3W3I5PMK/q9TcZhZaxJEk9DadV35aCREiSucv3Bj7bXlVvFvtro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773163074; c=relaxed/simple; bh=dFBW1esMyuAMDnGGVmYCP5OFXGVjP11B15JkWZWu76g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=pqdyYY1RgOY07nQz9j3iZcGQfuVpjwRfzCXP2HJZ7Ycfeuv4LJmkKNRe9tUSnT52CHWBbOC8ejmwwCMLJHjZ+GRFsw3Ect1bYDWhMz2JCV68OprIMYWlE3cUZaYTvloPUrH7/beTaoWVCVsSfM2SG4w670U4Etf0zZb8szV6YMU= 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=YPcgJ1cN; 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="YPcgJ1cN" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2aea7747aeeso7903555ad.2 for ; Tue, 10 Mar 2026 10:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773163072; x=1773767872; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=v2js8TxS1hyFxPiQX8Ai3FJPqj5QUTTd9TcNPsknpgQ=; b=YPcgJ1cNESr9iZZw6H872ZGH6hkzWyyiY8I6G9XnJbpd3V108BeorMqB0VgI4z+9ww GJF4fPxtchm2Slw5M6mO2H2hTCLwC+MQponioIRgTBFmD5ZpLaNK0+QOxvqDLAxXiNw6 2VO/4lD9jg0ug8WxGI1/t7QfO01/bZiAVVb5d64UUS97/FoHWWBzOuBJwX/iP9WjTqPu t8tRjdO35qU8z3QtwownN6xIVgIGi7AvAGg4ZThW9DFD1XNlGlV3lioWJK9ynF4Rdtpv UggES2MLFhi5tDhIXU6MgBJECsF+PENMnGuyD6T+TiW/E8H/alcHtYClHpNSqQ3E/rKe WW6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773163072; x=1773767872; h=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=v2js8TxS1hyFxPiQX8Ai3FJPqj5QUTTd9TcNPsknpgQ=; b=rwNOis+t7yRDFKnu2t2zeO/D2TzaNAitCjz9NTbCzIhrLdJWIoi7G/aCOnPO0xcDh0 eG5kabzkZhsT7vHN8AoRrxScWR2csvcV4PQjuVEPo2v4ndnfB6Dtq1XoGT5Y3CSVkmgn 31Zfq0pTq9DERC9M2N5tkrOoS2eEn6cKRxyGSiu8csTUO0uQ2ScPkg1E+IORL6F9tNFh B/XBBCVLXRSWFnzQEd9872/fJm3XK5SddkmutRAs8ND8QIY0QsJzfsgOWvaHL3wwtOUA f0IPIkf9+WEfmWXn1cVWcPnuV2sdYaHJg2uXAhqmIBjX7bKOOHw7HDmP2kFLdIh37Nkn tcDw== X-Forwarded-Encrypted: i=1; AJvYcCVu0PtYeGoDr1jqidNlBHB2Z0ejFenvKtcIch2FNyzLMRYQd8e9M1g9iXgPR38jnDXcKWY46xe/RywFaWs=@vger.kernel.org X-Gm-Message-State: AOJu0YwklY5HeAbc0ci6K1ZL7jqo5NF6fUw7X1TpkRZ4kycn690MEm9j /MTPeRV99KihL5RwWcleax7dUXmJPPy7PNDmMXJ710Im91G12q+uJFMHdjIu+V5t/l2kljI9V3J XLDovfA== X-Received: from plbms4.prod.google.com ([2002:a17:903:ac4:b0:297:eb04:dff7]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:234a:b0:2ae:5eab:1338 with SMTP id d9443c01a7336-2ae82366c81mr142402395ad.8.1773163071674; Tue, 10 Mar 2026 10:17:51 -0700 (PDT) Date: Tue, 10 Mar 2026 10:17:50 -0700 In-Reply-To: <19935696-36cf-411b-af90-aabe6a98d7e7@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260203190711.458413-1-seanjc@google.com> <20260203190711.458413-3-seanjc@google.com> <19935696-36cf-411b-af90-aabe6a98d7e7@amd.com> Message-ID: Subject: Re: [PATCH 2/2] KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated From: Sean Christopherson To: Srikanth Aithal Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , Naveen N Rao , "Maciej S . Szmigiero" Content-Type: text/plain; charset="us-ascii" On Tue, Mar 10, 2026, Srikanth Aithal wrote: > > Hello Sean, > > From next-20260304 onwards [1], including recent next kernel next-20260309, > booting an SEV-ES guest on AMD EPYC Turin and AMD EPYC Genoa has been > failing. However, on EPYC Milan, the SEV-ES guest boots fine. ... > Bisecting shows that this commit is the first bad one. When I revert it, I > am able to boot the SEV-ES guest successfully on both Turin and Genoa > platforms: > > e992bf67bcbab07a7f59963b2c4ed32ef65c8431 is the first bad commit > commit e992bf67bcbab07a7f59963b2c4ed32ef65c8431 > Author: Sean Christopherson > Date: Tue Feb 3 11:07:10 2026 -0800 Gah, I hate how KVM manages intercepts for SEV-ES+. Though to a large extent I blame the architecture for not simply making CR{0,4,8} intercept trap-like. Side topic, is the host actually allowed to trap CR3 writes? That seems like a huge gaping security flaw, especially for SNP+. Anyways, this should fix the immediate problem. diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 33172f0e986b..b6072872b785 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -237,7 +237,8 @@ static void avic_deactivate_vmcb(struct vcpu_svm *svm) vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK | X2APIC_MODE_MASK); vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK; - svm_set_intercept(svm, INTERCEPT_CR8_WRITE); + if (!sev_es_guest(svm->vcpu.kvm)) + svm_set_intercept(svm, INTERCEPT_CR8_WRITE); /* * If running nested and the guest uses its own MSR bitmap, there Argh! The more I look at this code, the more frustrated I get. The unconditional setting of TRAP_CR8_WRITE for SEV-ES+ is flawed. When AVIC is enabled, KVM doesn't need to trap CR8 writes because hardware will update the backing page. I'm guessing Windows doesn't support running as an SEV-ES guest, which is no one has noticed. Actually, it's worse than that. sync_cr8_to_lapic() will straight up clobber the backing page. Presumably hardware never actually uses TPR from the AVIC backing page, but it's still gross. sync_lapic_to_cr8() is also beyond useless. And all of sync code should pivot on guest_state_protected, not sev_es_guest(). For now, I'll just post the above (assuming it fixes the issue). But this code needs some love sooner than later.