linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Mattson <jmattson@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: Finish removing MPX from arch/x86?
Date: Tue, 4 Oct 2022 14:42:10 -0700	[thread overview]
Message-ID: <CALMp9eTD+GeiKK9E5_JUOy7YXPTq9z2f2LcyXZL5ypQ6vBHrHg@mail.gmail.com> (raw)
In-Reply-To: <c7a0b0f1-5a74-7f8c-b707-bce8086bc4c7@intel.com>

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.

  reply	other threads:[~2022-10-04 21:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-10-05 12:04 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALMp9eTD+GeiKK9E5_JUOy7YXPTq9z2f2LcyXZL5ypQ6vBHrHg@mail.gmail.com \
    --to=jmattson@google.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).