[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1a24380-ecfb-84d9-0122-5d52aa92f31b@intel.com>
Date: Sat, 25 Jun 2022 14:55:51 +0800
From: "Yang, Weijiang" <weijiang.yang@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH 16/19] KVM: x86: Enable CET virtualization for VMX and
advertise CET to userspace
On 6/16/2022 6:59 PM, Peter Zijlstra wrote:
> On Thu, Jun 16, 2022 at 04:46:40AM -0400, Yang Weijiang wrote:
>> Set the feature bits so that CET capabilities can be seen in guest via
>> CPUID enumeration. Add CR4.CET bit support in order to allow guest set CET
>> master control bit(CR4.CET).
>>
>> Disable KVM CET feature if unrestricted_guest is unsupported/disabled as
>> KVM does not support emulating CET.
>>
>> Don't expose CET feature if dependent CET bits are cleared in host XSS,
>> or if XSAVES isn't supported. Updating the CET features in common x86 is
>> a little ugly, but there is no clean solution without risking breakage of
>> SVM if SVM hardware ever gains support for CET, e.g. moving everything to
>> common x86 would prematurely expose CET on SVM. The alternative is to
>> put all the logic in VMX, but that means rereading host_xss in VMX and
>> duplicating the XSAVES check across VMX and SVM.
> Doesn't Zen3 already have SHSTK ?
From what I read, AMD only supports SHSTK now, IBT is not available. Given
possible implementation difference and the enabling code in vmx is shared by
SHSTK and IBT, I'd like to keep guest CET enabling code specific to vmx
now.
In the future, part of the code could be hoisted to x86 common to
support both.
Powered by blists - more mailing lists