Re: [PATCH] KVM: VMX: do not disable interception for MSR_IA32_SPEC_CTRL on eIBRS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On May 20, 2022, at 4:30 PM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> 
> On Fri, May 20, 2022, Jon Kohler wrote:
>> 
>> 
>>> On May 20, 2022, at 4:06 PM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>>> 
>>> On Fri, May 20, 2022, Jon Kohler wrote:
>>>> 
>>>>> On May 18, 2022, at 10:23 AM, Jon Kohler <jon@xxxxxxxxxxx> wrote:
>>>>> 
>>>>>> On May 17, 2022, at 9:42 PM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>>>>>>> +		if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) && data == BIT(0)) {
>>>>>> 
>>>>>> Use SPEC_CTRL_IBRS instead of open coding "BIT(0)", then a chunk of the comment
>>>>>> goes away.
>>>>>> 
>>>>>>> +			vmx->spec_ctrl = data;
>>>>>>> +			break;
>>>>>>> +		}
>>>>>> 
>>>>>> There's no need for a separate if statement.  And the boot_cpu_has() check can
>>>>>> be dropped, kvm_spec_ctrl_test_value() has already verified the bit is writable
>>>>>> (unless you're worried about bit 0 being used for something else?)
>>>> 
>>>> I was (and am) worried about misbehaving guests on pre-eIBRS systems spamming IBRS
>>>> MSR, which we wouldn’t be able to see today. Intel’s guidance for eIBRS has long been
>>>> set it once and be done with it, so any eIBRS aware guest should behave nicely with that.
>>>> That limits the blast radius a bit here.
>>> 
>>> Then check the guest capabilities, not the host flag.
>>> 
>>> 	if (data == SPEC_CTRL_IBRS &&
>>> 	    (vcpu->arch.arch_capabilities & ARCH_CAP_IBRS_ALL))
>> 
>> So I originally did that in my first internal patch; however, the code you wrote is
>> effectively the code I wrote, because cpu_set_bug_bits() already does that exact
>> same thing when it sets up X86_FEATURE_IBRS_ENHANCED. 
>> 
>> Is the boot cpu check more expensive than checking the vCPU perhaps? Otherwise,
>> checking X86_FEATURE_IBRS_ENHANCED seemed like it might be easier
>> understand for future onlookers, as thats what the rest of the kernel keys off of
>> when checking for eIBRS (e.g. in bugs.c etc). 
> 
> Cost is irrelevant, checking X86_FEATURE_IBRS_ENHANCED is simply wrong.  Just
> because eIBRS is supported in the host doesn't mean it's advertised to the guest,
> e.g. an older VM could have been created without eIBRS and then migrated to a host
> that does support eIBRS.  Now you have a guest that thinks it needs to constantly
> toggle IBRS (I assume that's the pre-eIBRS behavior), but by looking at the _host_
> value KVM would assume it's a one-time write and not disable interception.

Ahhhhhh, gotcha, ok I understand the nuance here. Off to v3 I go. 

Thanks again!





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux