[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d9abeb5d-989b-1b38-4551-1ccc50c7f400@intel.com>
Date: Thu, 16 Jun 2022 23:27:08 +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 ?
Hmm, you remind me of reading more specs from AMD... I'll check their HW
solution
if it's available.
Powered by blists - more mailing lists