On Tue, Oct 4, 2022 at 2:07 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 10/4/22 11:21, Jim Mattson wrote:
> > On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <dave.hansen@xxxxxxxxx> 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.
