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;
Message-ID: <3d150139-55ad-ff33-d6fd-4c2123ebd37b@intel.com>
Date:   Thu, 20 Jul 2023 09:55:00 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v3 00/21] Enable CET Virtualization
To:     Sean Christopherson <seanjc@google.com>
CC:     <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <peterz@infradead.org>,
        <rppt@kernel.org>, <binbin.wu@linux.intel.com>,
        <rick.p.edgecombe@intel.com>, <john.allen@amd.com>,
        Chao Gao <chao.gao@intel.com>
References: <20230511040857.6094-1-weijiang.yang@intel.com>
 <ZIufL7p/ZvxjXwK5@google.com>
 <147246fc-79a2-3bb5-f51f-93dfc1cffcc0@intel.com>
 <ZIyiWr4sR+MqwmAo@google.com>
 <c438b5b1-b34d-3e77-d374-37053f4c14fa@intel.com>
 <ZJYF7haMNRCbtLIh@google.com>
 <e44a9a1a-0826-dfa7-4bd9-a11e5790d162@intel.com>
 <ZLg8ezG/XrZH+KGD@google.com>
Content-Language: en-US
From:   "Yang, Weijiang" <weijiang.yang@intel.com>
In-Reply-To: <ZLg8ezG/XrZH+KGD@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVNNS2t3YmpNOGFJQ01OMms3RnlTcHByWUQ5eTE1eHYydmhMK28xalZqcUtY?=
 =?utf-8?B?c1JLQTdvWUFIaENXUGJZVUxiSHlZMS84ZjZhQTd3YnhNYWkyRS9oaDZHV1lN?=
 =?utf-8?B?MzN4ZnNRc2s0eW5zZW81NXRuMVpkc1ZQSHlnVU0yaTIwbDZkQTlvcGJsWXZr?=
 =?utf-8?B?T201TXR1VkVTcjZrQW1aZmc2ditxREkvdzM5OVNYbm1qV2VaWFRJSHlDNmNn?=
 =?utf-8?B?RjI2YlUvbHQvVVREYUZoaitPVGwxdzJ1ZFZMbDk3R2U5Rm4yVzlod2s5ajJ1?=
 =?utf-8?B?MngvOVlsL2ptVzdhenpnVVJqemtPeVFDN0dZb2NnZEVqcUNnVkVVaVJXa1N1?=
 =?utf-8?B?QXUvSWpwOUp4bEhOOTc1aUhydis0N3hQRkRrRjlRaDR4TmJIWFpUK3Q4UjRp?=
 =?utf-8?B?czg1d1FabDdEeUlFMkQ3SXhaeE5nZlp1MW1kcHZUUEcyRVZxbGFDYzB3TklJ?=
 =?utf-8?B?cWZjM3VIR3lyMFk0NjVEdHlDNDAvdGM1U1hOa1ErK1U4QUN0SEZwWm5OaWNQ?=
 =?utf-8?B?YSs4TDQrYnNQbW41Sk1DcUUyVldOMERONVM3YXk5c2JVblBCV0hrWUJIeitJ?=
 =?utf-8?B?aS9aS0ZEMkRwZ25PbkJZNmNybVpwTVhVbmIrMkNhMXVYY3k5L21rMjZmWVN2?=
 =?utf-8?B?ajVQYW8wYTkwamVFMlBtclQ4SmxRdERQNG1LRUVRYVRTVWRnUWFBdlgwdzZT?=
 =?utf-8?B?Rks5TEUzK3FMaTRXZVVQTnFQUGp1UGRRY21yelBTOExjaXloekVwME5Fc09y?=
 =?utf-8?B?RWV1OWNDUUp6M0JObkFTSjJIa0lMNUFzQStOclVuY2VDdXkzR2lUc0FuUmNH?=
 =?utf-8?B?VmhobytNblFQZXk5QXh0U25LejdKKzNwSUdmTUNPcXlmQ1dtWG1aZVA5cjNS?=
 =?utf-8?B?czFTK29WQk1uU0pCbjhBNmlUNFpFbE56UmtYYlpUdnczQTZ0QjF6WjcrV05x?=
 =?utf-8?B?b2dwK2IzQVh6UzJRZ2FQK3Y1eEJMWnJtUkRiRFQ4Ly9RNTJtVkFtUkNTUWZL?=
 =?utf-8?B?RGVjOHBFeWVFN0hnRnkrZWdpLzdyT0NLM0xIWnhDN21uOEl5MDJCS09xNmsx?=
 =?utf-8?B?NXd0Wkx5dStKbFVmalMvd0preERhQllIRlNicGE1QnZJTElLb2pSZS9TRHBk?=
 =?utf-8?B?YVNKakhwMmNJWGxnTGZWNlhpei9hY1hCL0R3ZzM5bHpNRFBlcG54VmJwRllI?=
 =?utf-8?B?aUcrRjFVc2s2UDFGMFltSVg4amdUcXZMNEQyYi8zOTdrM2QvUFZHOWhmNHM3?=
 =?utf-8?B?NjVnNXgwUEtlZXRoeVk4V3Y2SnIxUlFYZ010ZDZLd292ejJVVm9EcTJLc1V4?=
 =?utf-8?B?UVQrSXRDRG9zR0xTd3R0SUYzU1llbW1kSitGUDM0MUIrWWR6ZnhYazBMMFBR?=
 =?utf-8?B?azVmSloxc2dBYkRFYTBJOU5FeUxRMG1pRURjb1JNNDMyMW5VZ29WUHBjaHRn?=
 =?utf-8?B?VFNtYUs3alNqdUdLRjd5d2thOUlvSXBSZ3ZyK2xwK2pueTM5TFd4NzZIZmxk?=
 =?utf-8?B?Wlczcm9JSFVKamlmSnUzQlJzekJEVWxzZTlNSUNQYktLVnpST2FabEQ2TGJ4?=
 =?utf-8?B?NElsemNTbnZLeDF0OUhuZjByNXB4M3luaXRKZkZESlpUcGRtdzZXeFhVU3Js?=
 =?utf-8?B?bTVVcE8wZXJjNjFWU0FvTnBtUlR5QUxVSC9Xd09CajdCVnpJU0NYVEtGQlNL?=
 =?utf-8?B?RjQzUlZLV3NNNnJDOEI1dGlpNE5YMWVNVi9FUmFTVklGU1FtQUl4aVdWTlF4?=
 =?utf-8?B?bFBScjM2YVU5UXMxRUp4ckF3aVk1NHZvQnhjVlNuTlZGMENqZmhrZG9SQmpO?=
 =?utf-8?B?NWVXMzZIQ09Od2xLOWxQaXk1VE5id05IWk9Qb0JUcC9yRldSQUJXMVVkMkhB?=
 =?utf-8?B?RkNRQmRBalJQZ3BhME14ak9OYUJmdHhTeUdydUhHekRTNzRSeUR0TW1SUnFp?=
 =?utf-8?B?Uzk5Y2JYb0Q5VDFNalBwVU44TFBteE9lYTNvZ3dHNVh4ZUE0b1hua3YzcVhl?=
 =?utf-8?B?SUprT2t0U0ZoVHhqS3VlQUMvK0h5UWR3QnhldDRURURGS2NkUnBOYmNGaGZJ?=
 =?utf-8?B?VUlkSURXL29BZmk2cHA3b0MxRFNJeDlwdlROME9yREU3OXV6S3B2VUZiTEZO?=
 =?utf-8?B?MXJ0MW5wWlZoUGg0emJ5TjR6RlZvWEw5OUhhcWRTcE8vZXBuZ2hjU3l3VENT?=
 =?utf-8?B?clE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 096400b4-ec13-4faf-7311-08db88c459ad
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4965.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2023 01:55:10.5912
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3EGYf5lxBRHTRNJvrT/zCidCh/EtvGWxXqrHSkAOf1soOGRcoohbC8clpaQwSmLEW0pBOj9FYui8SrVwUGgtOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB5921
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 7/20/2023 3:41 AM, Sean Christopherson wrote:
> [...]
> My understanding is that PL[0-2]_SSP are used only on transitions to the
> corresponding privilege level from a *different* privilege level.  That means
> KVM should be able to utilize the user_return_msr framework to load the host
> values.  Though if Linux ever supports SSS, I'm guessing the core kernel will
> have some sort of mechanism to defer loading MSR_IA32_PL0_SSP until an exit to
> userspace, e.g. to avoid having to write PL0_SSP, which will presumably be
> per-task, on every context switch.
>
> But note my original wording: **If that's necessary**

Thanks!

I think host SSS enabling won't happen in short-term, handling the guest 
supervisor

states in KVM side is doable.

>
> If nothing in the host ever consumes those MSRs, i.e. if SSS is NOT enabled in
> IA32_S_CET, then running host stuff with guest values should be ok.  KVM only
> needs to guarantee that it doesn't leak values between guests.  But that should
> Just Work, e.g. KVM should load the new vCPU's values if SHSTK is exposed to the
> guest, and intercept (to inject #GP) if SHSTK is not exposed to the guest.

Yes, these handling have been covered by the new version.

>
> And regardless of what the mechanism ends up managing SSP MSRs, it should only
> ever touch PL0_SSP, because Linux never runs anything at CPL1 or CPL2, i.e. will
> never consume PL{1,2}_SSP.
>
> Am I missing something?

I think, guest PL{0,1,2}_SSP can be handled as a bundle to make the 
handling easy(instead of handling each

separately) because guest can be non-Linux systems, as you said before 
they could even be used as scratch registers.

But for host side as it's Linux, I can omit reloading/resetting host 
PL{1,2}_SSP when vCPU thread is preempted.

I will post new version to community if above is minor divergence.