[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2d6d62d-09be-4940-9c6e-92f80811587f@intel.com>
Date: Thu, 16 May 2024 08:36:56 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
Weijiang Yang <weijiang.yang@...el.com>
Cc: rick.p.edgecombe@...el.com, pbonzini@...hat.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/16/24 07:39, Sean Christopherson 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.
I'm basically arguing for the path of least resistance (at least to start).
We should just do what takes the least amount of code for now that
results in mostly sane behavior, then debate about making it perfect later.
In other words, let's say the place we'd *IDEALLY* end up is that guests
can have any random FPU state which is disconnected from the host. But
the reality, for now, is that the host needs to have XFEATURE_CET_USER
set in order to pass it into the guest and that means keeping
X86_FEATURE_SHSTK set.
If you want guest XFEATURE_CET_USER, you must have host
X86_FEATURE_SHSTK ... for now.
Powered by blists - more mailing lists