Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 26 Jun 2023 09:28:24 -0700
In-Reply-To: <52ea8386-8652-dd91-23de-9d35781cb131@amd.com>
Mime-Version: 1.0
References: <20230524155339.415820-1-john.allen@amd.com> <20230524155339.415820-7-john.allen@amd.com>
 <161174d013dff42ddfd2950fe33a8054f45c223e.camel@intel.com>
 <ZINGaJnNJ54+klsD@johallen-workstation.lan> <9ef2faeaa38e667bd4daa8ee338d4cade452c76c.camel@intel.com>
 <ZJYaNSzup+yuYxNy@google.com> <52ea8386-8652-dd91-23de-9d35781cb131@amd.com>
Message-ID: <ZJm64a7IKuSDS9bz@google.com>
Subject: Re: [RFC PATCH v2 6/6] KVM: SVM: Add CET features to supported_xss
From:   Sean Christopherson <seanjc@google.com>
To:     Tom Lendacky <thomas.lendacky@amd.com>
Cc:     Rick P Edgecombe <rick.p.edgecombe@intel.com>,
        "john.allen@amd.com" <john.allen@amd.com>,
        Weijiang Yang <weijiang.yang@intel.com>,
        "bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Mon, Jun 26, 2023, Tom Lendacky wrote:
> On 6/23/23 17:18, Sean Christopherson wrote:
> > On Fri, Jun 09, 2023, Rick P Edgecombe wrote:
> > > Also, since the host might have CR4.CET set for its own reasons, if the host
> > > handled an exit with the the guests MSR_IA32_S_CET set it could suddenly be
> > > subjected to CET enforcement that it doesn't expect. Waiting to restore it
> > > until returning to the guest is too late.
> > > 
> > > At least that's the reasoning on the VMX side as I understand it
> > 
> > The APM doesn't come right out and say it, but I assume/hope that S_CET is saved
> > on VMRUN and loaded on #VMEXIT, i.e. is the same as VMX for all intents and
> > purposes.
> > 
> > The host save state definitely has a field for S_CET, and VMRUN documents that the
> > guest values are loaded, I just can't find anything in the APM that explicitly states
> > how host S_CET and friends are handled.  E.g. in theory, they could have been
> > shoved into VMSAVE+VMLOAD, though I very much doubt that's the case.
> 
> Yes, the host value is saved/restored on VMRUN/#VMEXIT. Anything that is in
> the VMCB Save Area (the non-SEV-ES save area) is fully virtualized (unless
> noted otherwise) and doesn't require special processing to save/restore the
> host values.

Would it makes sense to add a column in "Table B-2. VMCB Layout, State Save Area"
to specify whether a field is handled by VMRUN+#VMEXIT vs. VMLOAD+VMSAVE?  I can't
find anywhere in the APM where it explicitly states that VMRUN+#VMEXIT context
switches everything in the Save Area except the fields listed in "15.5.2 VMSAVE
and VMLOAD Instructions".

"15.5 VMRUN Instruction" kinda sorta covers that behavior, but the information is
either incomplete or stale, e.g. for host state it says "at least the following"

  Saving Host State. To ensure that the host can resume operation after #VMEXIT,
  VMRUN saves at least the following host state information:

but for guest state it says "the following"

  Loading Guest State. After saving host state, VMRUN loads the following guest
  state from the VMCB:

and then both provide incomplete lists of state.  A pedantic reading of the guest
case suggests that there's a large pile of state that *isn't* loaded, and the host
case isn't all that helpful because it's way too handwavy.