On 3/31/2023 4:05 AM, Sean Christopherson wrote:
On Thu, Mar 30, 2023, John Allen wrote:
On Thu, Mar 30, 2023 at 01:37:38PM +0800, Yang, Weijiang wrote:
On 3/29/2023 8:16 AM, Yang, Weijiang wrote:
Now that the baremetal series has been accepted, how do we want to
proceed? I think I'd like to send a refreshed version based on the
version that was accpeted, but I'd want to wait to base it on a new
version of Weijiang's kvm/vmx series (if one is planned).
Patch 1/7 did what I wanted to implement to support AMD SHSTK, my next
version will continue refactoring them in vmx scope, then� your series may
pick up the helper and modify accordingly.
Please note, in my series, I removed check for MSR_IA32_PL{0,1,2}_SSP since
they're not supported right now, but your series supports for the MSRs, so
you have to change the helper a bit to adapt to your patches.
The reason we decided to include the PL{0,1,2}_SSP MSRs is that even
though linux doesn't support supervisor shadow stack, a non-linux guest
OS might support it and could make use of the MSRs. It could be
something the vmx patches might want to account for as well
And emulating/virtualizing those MSRs is mandatory unless KVM can hide those MSRs
without violating the architecture (been a while since I looked at CET). If the
architecture does allow enumerating support for userspace but not supervisor, then
ideally the two would be enabled separately in KVM, e.g. so that that if one is
completely busted, we might be able to precisely revert only the broken code.
OK, I'll add a separate patch to expose these supervisor MSRs but they
are not accessible on Intel
platform right now, i.e., resulting into #GP.
Meanwhile CPUID(7,1).EDX.bit 18 is always cleared to tell guest
supervisor SHSTK is not supported.
Allen can modify per AMD needs.
