All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosry@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yosry Ahmed <yosry@kernel.org>
Subject: [PATCH v3 0/5] KVM: x86: Fix EFER reserved bits initialization
Date: Mon, 13 Jul 2026 18:10:15 +0000	[thread overview]
Message-ID: <20260713181020.2735367-1-yosry@kernel.org> (raw)

v3 of fixing EFER reserved bits initialization on vendor module reload,
and move them into kvm_caps. I reworked and reordered the patches such
that we go straight to reinitializing the EFER reserved bits, instead of
first re-reserving the bits on vendor init if nested=0.

The motivation for the previous approach was simpler backports, but
practically the fixes don't apply cleanly anyway to most stable kernels
due to EFER.LMSLE handling being introduced very recently.

v2 -> v3:
- Drop KVM_SET_SREGS* validity checks fixes, sent separately.
- Re-ordered and reworked the patches to re-initialize EFER reserved
  bits right away.
- Drop the per-vendor op for EFER caps initialization, instead move
  EFER.SVME and EFER.LMSLE handling to generic x86 code.

Yosry Ahmed (5):
  KVM: x86: Move enabling EFER.SVME and EFER.LMSLE to generic EFER setup
  KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported
  KVM: x86: Always initialize EFER reserved bits on vendor
    initialization
  KVM: x86: Reverse the polarity of efer_reserved_bits
  KVM: x86: Move supported EFER bits to kvm_caps

 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/msrs.c             | 21 ++-------------------
 arch/x86/kvm/msrs.h             |  1 -
 arch/x86/kvm/svm/svm.c          |  4 ----
 arch/x86/kvm/x86.c              | 18 +++++++++++++++---
 5 files changed, 19 insertions(+), 27 deletions(-)


base-commit: 3aec122bdcaf6f8c4ecfc7f6adf6773015ced676
-- 
2.55.0.141.g00534a21ce-goog


             reply	other threads:[~2026-07-13 18:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13 18:10 Yosry Ahmed [this message]
2026-07-13 18:10 ` [PATCH v3 1/5] KVM: x86: Move enabling EFER.SVME and EFER.LMSLE to generic EFER setup Yosry Ahmed
2026-07-13 18:10 ` [PATCH v3 2/5] KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported Yosry Ahmed
2026-07-13 18:42   ` sashiko-bot
2026-07-13 18:50     ` Yosry Ahmed
2026-07-13 18:10 ` [PATCH v3 3/5] KVM: x86: Always initialize EFER reserved bits on vendor initialization Yosry Ahmed
2026-07-13 18:10 ` [PATCH v3 4/5] KVM: x86: Reverse the polarity of efer_reserved_bits Yosry Ahmed
2026-07-13 18:10 ` [PATCH v3 5/5] KVM: x86: Move supported EFER bits to kvm_caps Yosry Ahmed

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=20260713181020.2735367-1-yosry@kernel.org \
    --to=yosry@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.