From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4E09EB64DC for ; Mon, 26 Jun 2023 16:30:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231543AbjFZQ3t (ORCPT ); Mon, 26 Jun 2023 12:29:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229901AbjFZQ3Z (ORCPT ); Mon, 26 Jun 2023 12:29:25 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DF9F109 for ; Mon, 26 Jun 2023 09:28:26 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-53fa2d0c2ebso1421262a12.1 for ; Mon, 26 Jun 2023 09:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687796906; x=1690388906; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=LcHOcPJNQNsmb8p5lWxRB01eVrgr+kLMT1qIAAPh7K0=; b=0C+CyWG0GM0drwvZ0vSkvRMtOSGBuPAKMRT9q9dRUNLgsTmg4HKMwjYpYcDTv57Tls zSJGXTxI6enbEMjyacQKdeUQcj8wenqCDj2auDP4WOwTdqv2mkFXXqtCw4dMrc+GL4UZ jMIwhWZ4zIFfAKfoAP3ki2pyE1yo3gcNAKNksNqGCMY5cPjA26nOLRCRSKzJhhet5mWN Lj+T5CX9IyCLMiU4f1sJFb9xKm6JQ+02iH15WBZYqIissVx0r560CxYKbPw7/cXX53LO 9dXRlcIb47Yj3OJ4myuWHzraEWB281b77yaf5mLKXXkCsUj10GzQiqE/oeSurlo+Yjsv Or9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687796906; x=1690388906; 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=LcHOcPJNQNsmb8p5lWxRB01eVrgr+kLMT1qIAAPh7K0=; b=gHXRJ24qwjZ7DIyAOZ5WQwACPrCHAW+uaii0eCJsurFsWONHcuucuDzfoycHITPYHn STlKxcIlc86y1iEuliLSWu6EYGvdfFodrt0GNQ7hgpBWmMXWJvaei8oh7/OuU9TN/AEV 8LajDI0zIlrHLwcqvo9LSDktFFWbYiG3lwFpo1qwAOJCfRfj+twYozEjcyT6Vbg6fHJJ OOw2bMDPm8CzSr741na78cee5AAa7sVjx8ze9UzEiaDBIFiet8T7do7pkwswX2G/20us nnpStttbfn9+ajR1G/lizDQqma1Nl6ZLtxTuiQW8tLi2C+1wTx9npS5Jd9+3v90sc40c oTmg== X-Gm-Message-State: AC+VfDx6Y8lXNmNf6zFhSHb8Nkpl5UHCYbU9rQ5s+IF5rNO50hzqfWhr 58oio9jo89YNhP7FEfLivqVaHg60BN8= X-Google-Smtp-Source: ACHHUZ7Wk6snFRWIjCiJHNIBQLZ/Mb6v/fisOviOSg2CIlQCenmsh0/FaAZPBkXB3y1IHQ/hHD+ZHUSwhWE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:d244:0:b0:540:ca81:4a1d with SMTP id t4-20020a63d244000000b00540ca814a1dmr3818129pgi.11.1687796906100; Mon, 26 Jun 2023 09:28:26 -0700 (PDT) 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> <9ef2faeaa38e667bd4daa8ee338d4cade452c76c.camel@intel.com> <52ea8386-8652-dd91-23de-9d35781cb131@amd.com> Message-ID: Subject: Re: [RFC PATCH v2 6/6] KVM: SVM: Add CET features to supported_xss From: Sean Christopherson To: Tom Lendacky Cc: Rick P Edgecombe , "john.allen@amd.com" , Weijiang Yang , "bp@alien8.de" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "andrew.cooper3@citrix.com" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.