We zapped the userspace MPX ABIs and most of its supporting code in here:
45fc24e89b7c ("x86/mpx: remove MPX from arch/x86")
But, the XSAVE enabling and KVM code were left in place. This let folks
at least keep running guests with MPX.
It's been a couple of years and I don't think I've had a single person
opine about the loss of MPX. Intel also followed through and there's no
MPX to be found on newer CPUs like my "Tiger Lake" 11th Gen Intel(R)
Core(TM) i7-1165G7.
Is it time to zap MPX from arch/x86/kvm/?
On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <[email protected]> wrote:
>
> We zapped the userspace MPX ABIs and most of its supporting code in here:
>
> 45fc24e89b7c ("x86/mpx: remove MPX from arch/x86")
>
> But, the XSAVE enabling and KVM code were left in place. This let folks
> at least keep running guests with MPX.
>
> It's been a couple of years and I don't think I've had a single person
> opine about the loss of MPX. Intel also followed through and there's no
> MPX to be found on newer CPUs like my "Tiger Lake" 11th Gen Intel(R)
> Core(TM) i7-1165G7.
>
> Is it time to zap MPX from arch/x86/kvm/?
Until Google Cloud retires all of our MPX-capable hardware, we will
require MPX support in KVM.
Removing that support would leave VMs with MPX enabled in XCR0 with
nowhere to go.
On 10/4/22 11:21, Jim Mattson wrote:
> On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <[email protected]> wrote:
>>
>> We zapped the userspace MPX ABIs and most of its supporting code in here:
>>
>> 45fc24e89b7c ("x86/mpx: remove MPX from arch/x86")
>>
>> But, the XSAVE enabling and KVM code were left in place. This let folks
>> at least keep running guests with MPX.
>>
>> It's been a couple of years and I don't think I've had a single person
>> opine about the loss of MPX. Intel also followed through and there's no
>> MPX to be found on newer CPUs like my "Tiger Lake" 11th Gen Intel(R)
>> Core(TM) i7-1165G7.
>>
>> Is it time to zap MPX from arch/x86/kvm/?
>
> Until Google Cloud retires all of our MPX-capable hardware, we will
> require MPX support in KVM.
>
> Removing that support would leave VMs with MPX enabled in XCR0 with
> nowhere to go.
Is this because you migrate guest VMs between hosts? A _potential_ VM
migration target host is ineligible if it has a subset of the features
of the source host?
Would it be _possible_ to leave existing VMs alone, but to stop
enumerating MPX to newly-created VMs? I don't know how long-lived your
VMs are, but I'm hoping that the ones that know about MPX will all die
naturally of old age at some point.
On Tue, Oct 4, 2022 at 2:07 PM Dave Hansen <[email protected]> wrote:
>
> On 10/4/22 11:21, Jim Mattson wrote:
> > On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <[email protected]> wrote:
> >>
> >> We zapped the userspace MPX ABIs and most of its supporting code in here:
> >>
> >> 45fc24e89b7c ("x86/mpx: remove MPX from arch/x86")
> >>
> >> But, the XSAVE enabling and KVM code were left in place. This let folks
> >> at least keep running guests with MPX.
> >>
> >> It's been a couple of years and I don't think I've had a single person
> >> opine about the loss of MPX. Intel also followed through and there's no
> >> MPX to be found on newer CPUs like my "Tiger Lake" 11th Gen Intel(R)
> >> Core(TM) i7-1165G7.
> >>
> >> Is it time to zap MPX from arch/x86/kvm/?
> >
> > Until Google Cloud retires all of our MPX-capable hardware, we will
> > require MPX support in KVM.
> >
> > Removing that support would leave VMs with MPX enabled in XCR0 with
> > nowhere to go.
>
> Is this because you migrate guest VMs between hosts? A _potential_ VM
> migration target host is ineligible if it has a subset of the features
> of the source host?
Yes, we migrate between hosts. On a kernel upgrade, most VMs are
migrated. (Some, like those with pass-through GPUs, are terminated on
host maintenance.)
The problem is that KVM_SET_XCRS will fail on an MPX-incapable target
host if the vCPU has XCR0[4:3] set.
> Would it be _possible_ to leave existing VMs alone, but to stop
> enumerating MPX to newly-created VMs? I don't know how long-lived your
> VMs are, but I'm hoping that the ones that know about MPX will all die
> naturally of old age at some point.
Once we get buy-in from all stakeholders, then we have to give
customers one year notice, and only then can we stop enumerating the
feature for newly created VMs.
While most of our VMs don't live long, there is a long, long tail. If
I had to guess, it might take anywhere from 5 to 10 years for the
remaining MPX VMs to die off.
On 10/4/22 19:34, Dave Hansen wrote:
> We zapped the userspace MPX ABIs and most of its supporting code in here:
>
> 45fc24e89b7c ("x86/mpx: remove MPX from arch/x86")
>
> But, the XSAVE enabling and KVM code were left in place. This let folks
> at least keep running guests with MPX.
>
> It's been a couple of years and I don't think I've had a single person
> opine about the loss of MPX. Intel also followed through and there's no
> MPX to be found on newer CPUs like my "Tiger Lake" 11th Gen Intel(R)
> Core(TM) i7-1165G7.
>
> Is it time to zap MPX from arch/x86/kvm/?
I agree that the likelihood of anybody complaining about MPX is low but
Jim is right that the timeline for removing it is unfortunately quite long.
Removing MPX from XFEATURE_MASK_USER_SUPPORTED is possible, though we
need to add a new XFEATURE_MASK_GUEST_SUPPORTED that includes MPX. I'll
take a look.
Also, it's worth noting that MPX lives in the sigcontext ABI because it
uses the non-compacted format. Because of that it is not possible to
remove the structs from include/asm/fpu/types.h, for example.
Paolo