[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a170e420-efc3-47f9-b825-43229c999c0d@intel.com>
Date: Mon, 20 May 2024 17:43:51 +0800
From: "Yang, Weijiang" <weijiang.yang@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, Thomas Gleixner
<tglx@...utronix.de>
CC: <rick.p.edgecombe@...el.com>, <pbonzini@...hat.com>,
<dave.hansen@...el.com>, <x86@...nel.org>, <kvm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <peterz@...radead.org>, <chao.gao@...el.com>,
<mlevitsk@...hat.com>, <john.allen@....com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
advertise to userspace
On 5/17/2024 10:26 PM, Sean Christopherson wrote:
> On Fri, May 17, 2024, Thomas Gleixner wrote:
>> On Thu, May 16 2024 at 07:39, Sean Christopherson wrote:
>>> On Thu, May 16, 2024, Weijiang Yang wrote:
>>>> We synced the issue internally, and got conclusion that KVM should honor host
>>>> IBT config. In this case IBT bit in boot_cpu_data should be honored. With
>>>> this policy, it can avoid CPUID confusion to guest side due to host ibt=off
>>>> config.
>>> What was the reasoning? CPUID confusion is a weak justification, e.g. it's not
>>> like the guest has visibility into the host kernel, and raw CPUID will still show
>>> IBT support in the host.
>>>
>>> On the other hand, I can definitely see folks wanting to expose IBT to guests
>>> when running non-complaint host kernels, especially when live migration is in
>>> play, i.e. when hiding IBT from the guest will actively cause problems.
>> I have to disagree here violently.
>>
>> If the exposure of a CPUID bit to a guest requires host side support,
>> e.g. in xstate handling, then exposing it to a guest is simply not
>> possible.
> Ya, I don't disagree, I just didn't realize that CET_USER would be cleared in the
> supported xfeatures mask.
For host side support, fortunately, this patch already has some checks for that. But for userspace
CPUID config, it allows IBT to be exposed alone.
IIUC, this series tries to tie IBT to SHSTK feature, i.e., IBT cannot be exposed as an independent
feature to guest without exposing SHSTK at the same time. If it is, then below patch is not needed
anymore:
https://lore.kernel.org/all/20240219074733.122080-3-weijiang.yang@intel.com/
I'd check and clear IBT bit from CPUID when userspace enables only IBT via KVM_SET_CPUID2.
And update related code of the series given the implicit dependency.
Thanks!
Powered by blists - more mailing lists