From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (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 B4FC7478851 for ; Fri, 21 Aug 2026 13:28:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.71 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787318923; cv=none; b=Qhk9sh18ZGAdgu6Fd4WCzSlPi+d7McMty53bx57BZelCGKZiqXa7WYvJw/03vP4HGk7p7ssHeDEafTHgRc+MjNM0JUVzkcRRU1KaMsQlAh16w3Dk5+O4SMMHP1EoDbE5Ty1LU4yShOwBo7djOGBZhU8R2jiG2QakIZqed4m9P58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787318923; c=relaxed/simple; bh=8MXAlRp/lZOVNsZeGJaf8IGjpdU3o5msgIcYcSAxHvA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Wcjd48G4+c3wtcsDMYsjOjETYq9PKPuHhw3Nxg+Jpiahhxv5L2ObT02TZ6qnbTGbMQ53NOmuNRe6LQaD0EYSvhtPAKAN/cjUabIJDHptXNa1pojPIC3I6f0qSbGVE0TND3OiZoy4TxPBo7UwGwcFdE3m/Nnr5ebgJnXbOMZKWu0= 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=WLpjHETs; arc=none smtp.client-ip=209.85.216.71 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="WLpjHETs" Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-385d2703b64so2263606a91.1 for ; Fri, 21 Aug 2026 06:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1787318921; x=1787923721; darn=vger.kernel.org; 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=YX0fQ7Qjdf1AGjRX2lzd8yREGufMUdE4nTQS2ZIadXU=; b=WLpjHETs8XcuwLhsAPERLOAsKOWQWPgjowK+/U9jpiGN2Nlcgl4z0EOnTS/fHmAHZB rXQ9g/3husxTfZGPd1nYv1+ZmpHwiW5x8Xzt/xSNWNoFtKwkU33fmQEkXt4cR2KxDrhe 1CJXb87R4xxs6pwioAoLfeILhOIX4ArQEbEdvEZJwDoMed/18Z3B4PMvahSzqz+d270I 7axmYKluagCcQNRsubOwjRzGn3D/XlVf1WWuW3XAC6zlcD8NRXHkoxTlfYuKGXJWAUXU oTHiW7hoVYU/end87Vj0LFGy7ZBkFw7oLAv1WwJzEr7jtitEB3NxaAO7OYslGNULpvNh 6/sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787318921; x=1787923721; 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=YX0fQ7Qjdf1AGjRX2lzd8yREGufMUdE4nTQS2ZIadXU=; b=UiP+mHQdaD5niUPkzPxrWLklUiCsR2+wj2i6FTP4OLB5pVTO/DCVU0mnHtXSaq0UlN pAT+/Fumin1mE1ioQx49frNcpM7gAKdj1GY45592MOyl1cHM7Zv9E8rr0Pd//aPokBhR fpifZGMZOoL4O+aj4S2BsUGNkkS36UE3s6w2xGA76inqvDQlNNhXTtN/oyaOGz609ObX aju2xuvIriJ+Zqn3jh2+0KW7F0QOy9mBexghQzRRg8qpRW/YW11FUKU/l+xD6Dbtb3eV XRaOZ+WuVAkpjiit/lB5/EWRhNdYmsGTvReezbZf8xVELLS32Qmt5VwsLjaF9jwT9v12 fTwQ== X-Forwarded-Encrypted: i=1; AHgh+Rq69JDxHf4OuCpd5q423sajalhqhKKnJV0IXYREhJATEWy3FqeOW1SrhTUznStfS/r60/UEiQQSs14H/Jc=@vger.kernel.org X-Gm-Message-State: AFuF++kIefGtWcRuDT6U1U4W5JJizhBHAxaBhlTD6ETWSNJ9zQ+9oV79 rRomuTdJrhyG1g226bu1IAPK1Hj7RFOQQv7YF9l8hK1ehzA2FMEZBYYPQ8aCQoMCpO3bkv6jZMr 6OeQ33w== X-Received: from pgg24.prod.google.com ([2002:a05:6a02:4d98:b0:cbe:dc9e:aa41]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:57ef:b0:36d:b12b:f57d with SMTP id 98e67ed59e1d1-395a06363a2mr17704953a91.12.1787318920864; Fri, 21 Aug 2026 06:28:40 -0700 (PDT) Date: Fri, 21 Aug 2026 06:28:40 -0700 In-Reply-To: <829b5c18-6ffe-46fe-bfed-03d5ddde92d9@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260129063653.3553076-1-shivansh.dhiman@amd.com> <20260129063653.3553076-8-shivansh.dhiman@amd.com> <829b5c18-6ffe-46fe-bfed-03d5ddde92d9@amd.com> Message-ID: Subject: Re: [PATCH 7/7] KVM: SVM: Enable save/restore of FRED MSRs From: Sean Christopherson To: Shivansh Dhiman Cc: Nikunj A Dadhania , pbonzini@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, xin@zytor.com, nikunj.dadhania@amd.com, santosh.shukla@amd.com Content-Type: text/plain; charset="us-ascii" On Wed, Aug 19, 2026, Shivansh Dhiman wrote: > On 13-08-26 04:57, Sean Christopherson wrote: > >> Would you prefer it handled in svm_recalc_fred_msr_intercepts() instead > >> while setting intercepts? Or is there a better way to deal with this? > > > > Take a hard dependency on an upcoming APM update that states the control area > > is valid after shutdown, and rework KVM to not clobber control fields on shutdown > > interception. > > Sure, Sean. I'm thinking something like the diff below. It contains three > parts: > > 1. Clear the save area and offsets 60h, 61h, and 68h of the control area, > as per the APM. > > 2. Zero the intercepts as well. The APM doesn't require it, but it seemed > worthwhile so that the new intercepts are computed on a clean slate > rather than on top of whatever survived the triple fault. Is that worth > doing? My gut reaction is I don't see how this can possibly be safe or correct. How does the guest taking a series of faults have anything to do with what accesses KVM needs to intercept? > 3. For nested, same fields are copied to vmcb12 when a shutdown is intercepted > in L2. Clear them while copying so L1 gets a deterministic value > rather than whatever the hardware left behind. Does that seem like right > thing to do? No, because that violates the rule of "don't make stuff up". It could also be actively detrimental to L1's ability to debug issues (e.g. if hardware leaves breadcrumbs in the save area), and risks creating guest<=>host ABI that we don't want to support. > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index 83de3456df708..38843b29b21ec 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -1149,6 +1149,11 @@ int nested_svm_vmexit(struct vcpu_svm *svm) > vmcb12->control.event_inj = svm->nested.ctl.event_inj; > vmcb12->control.event_inj_err = svm->nested.ctl.event_inj_err; > > + if (vmcb02->control.exit_code == SVM_EXIT_SHUTDOWN) { > + vmcb12->control.int_ctl &= ~GENMASK(15, 0); > + vmcb12->control.int_state = 0; > + } > + > if (!kvm_pause_in_guest(vcpu->kvm)) { > vmcb01->control.pause_filter_count = vmcb02->control.pause_filter_count; > vmcb_mark_dirty(vmcb01, VMCB_INTERCEPTS); > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 519249e75420d..62b4feb9c3909 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -2090,7 +2090,11 @@ static int shutdown_interception(struct kvm_vcpu *vcpu) > * cannot be reinitialized, i.e. synthesizing INIT is futile. > */ > if (!sev_es_guest(vcpu->kvm)) { > - clear_page(svm->vmcb); > + struct vmcb_control_area *control = &svm->vmcb->control; > + memset(&svm->vmcb->save, 0, sizeof(svm->vmcb->save)); > + memset(control->intercepts, 0, sizeof(control->intercepts)); > + control->int_ctl &= ~GENMASK(15, 0); > + control->int_state = 0; > #ifdef CONFIG_KVM_SMM > if (is_smm(vcpu)) > kvm_smm_changed(vcpu, false); > > > Cheers, > Shivansh >