* Finish removing MPX from arch/x86?
@ 2022-10-04 17:34 Dave Hansen
2022-10-04 18:21 ` Jim Mattson
2022-10-05 12:04 ` Paolo Bonzini
0 siblings, 2 replies; 5+ messages in thread
From: Dave Hansen @ 2022-10-04 17:34 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H. Peter Anvin, kvm, linux-kernel,
Arjan van de Ven
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/?
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Finish removing MPX from arch/x86? 2022-10-04 17:34 Finish removing MPX from arch/x86? Dave Hansen @ 2022-10-04 18:21 ` Jim Mattson 2022-10-04 21:07 ` Dave Hansen 2022-10-05 12:04 ` Paolo Bonzini 1 sibling, 1 reply; 5+ messages in thread From: Jim Mattson @ 2022-10-04 18:21 UTC (permalink / raw) To: Dave Hansen Cc: Sean Christopherson, Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin, kvm, linux-kernel, Arjan van de Ven On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <dave.hansen@intel.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Finish removing MPX from arch/x86? 2022-10-04 18:21 ` Jim Mattson @ 2022-10-04 21:07 ` Dave Hansen 2022-10-04 21:42 ` Jim Mattson 0 siblings, 1 reply; 5+ messages in thread From: Dave Hansen @ 2022-10-04 21:07 UTC (permalink / raw) To: Jim Mattson Cc: Sean Christopherson, Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin, kvm, linux-kernel, Arjan van de Ven On 10/4/22 11:21, Jim Mattson wrote: > On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <dave.hansen@intel.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Finish removing MPX from arch/x86? 2022-10-04 21:07 ` Dave Hansen @ 2022-10-04 21:42 ` Jim Mattson 0 siblings, 0 replies; 5+ messages in thread From: Jim Mattson @ 2022-10-04 21:42 UTC (permalink / raw) To: Dave Hansen Cc: Sean Christopherson, Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin, kvm, linux-kernel, Arjan van de Ven On Tue, Oct 4, 2022 at 2:07 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 10/4/22 11:21, Jim Mattson wrote: > > On Tue, Oct 4, 2022 at 10:45 AM Dave Hansen <dave.hansen@intel.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Finish removing MPX from arch/x86? 2022-10-04 17:34 Finish removing MPX from arch/x86? Dave Hansen 2022-10-04 18:21 ` Jim Mattson @ 2022-10-05 12:04 ` Paolo Bonzini 1 sibling, 0 replies; 5+ messages in thread From: Paolo Bonzini @ 2022-10-05 12:04 UTC (permalink / raw) To: Dave Hansen, Sean Christopherson, Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin, kvm, linux-kernel, Arjan van de Ven 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-10-05 12:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-04 17:34 Finish removing MPX from arch/x86? Dave Hansen 2022-10-04 18:21 ` Jim Mattson 2022-10-04 21:07 ` Dave Hansen 2022-10-04 21:42 ` Jim Mattson 2022-10-05 12:04 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).