[GIT PULL] KVM fixes for Linux 6.11-rc7

[GIT PULL] KVM fixes for Linux 6.11-rc7

[Paolo Bonzini]

Linus,

The following changes since commit 47ac09b91befbb6a235ab620c32af719f8208399:

  Linux 6.11-rc4 (2024-08-18 13:17:27 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 59cbd4eea48fdbc68fc17a29ad71188fea74b28b:

  KVM: Remove HIGH_RES_TIMERS dependency (2024-09-05 12:04:54 -0400)

Many small fixes that accumulated while I was on vacation...

----------------------------------------------------------------
x86:

- Fixup missed comments from the REMOVED_SPTE=>FROZEN_SPTE rename.

- Ensure a root is successfully loaded when pre-faulting SPTEs.

- Grab kvm->srcu when handling KVM_SET_VCPU_EVENTS to guard against accessing
  memslots if toggling SMM happens to force a VM-Exit.

- Emulate MSR_{FS,GS}_BASE on SVM even though interception is always disabled,
  so that KVM does the right thing if KVM's emulator encounters {RD,WR}MSR.

- Explicitly clear BUS_LOCK_DETECT from KVM's caps on AMD, as KVM doesn't yet
  virtualize BUS_LOCK_DETECT on AMD.

- Cleanup the help message for CONFIG_KVM_AMD_SEV, and call out that KVM now
  supports SEV-SNP too.

- Specialize return value of KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM),
  based on VM type

- Remove unnecessary dependency on CONFIG_HIGH_RES_TIMERS

- Note an RCU quiescent state on guest exit.  This avoids a call to rcu_core()
  if there was a grace period request while guest was running.

----------------------------------------------------------------
Leonardo Bras (1):
      kvm: Note an RCU quiescent state on guest exit

Maxim Levitsky (1):
      KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE and MSR_GS_BASE

Paolo Bonzini (1):
      Merge tag 'kvm-x86-fixes-6.11-rcN' of https://github.com/kvm-x86/linux into kvm-master

Ravi Bangoria (1):
      KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is missing

Sean Christopherson (2):
      KVM: x86/mmu: Check that root is valid/loaded when pre-faulting SPTEs
      KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS

Steven Rostedt (1):
      KVM: Remove HIGH_RES_TIMERS dependency

Tom Dohrmann (1):
      KVM: x86: Only advertise KVM_CAP_READONLY_MEM when supported by VM

Vitaly Kuznetsov (1):
      KVM: SEV: Update KVM_AMD_SEV Kconfig entry and mention SEV-SNP

Yan Zhao (1):
      KVM: x86/mmu: Fixup comments missed by the REMOVED_SPTE=>FROZEN_SPTE rename

 arch/x86/kvm/Kconfig             |  7 ++++---
 arch/x86/kvm/mmu/mmu.c           |  4 +++-
 arch/x86/kvm/mmu/spte.c          |  6 +++---
 arch/x86/kvm/mmu/spte.h          |  2 +-
 arch/x86/kvm/mmu/tdp_mmu.c       |  8 ++++----
 arch/x86/kvm/svm/svm.c           | 15 +++++++++++++++
 arch/x86/kvm/x86.c               |  5 ++++-
 include/linux/context_tracking.h |  6 ++++--
 include/linux/kvm_host.h         | 10 +++++++++-
 9 files changed, 47 insertions(+), 16 deletions(-)

Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

[pr-tracker-bot]

The pull request you sent on Fri,  6 Sep 2024 11:45:17 -0400:

> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d45111e52b81e0da6307bde9de8f2a5ac72d9ca9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

[Linus Torvalds]

On Fri, 6 Sept 2024 at 08:45, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> - Specialize return value of KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM),
>   based on VM type

Grr. This actually causes a build warning with clang, but I didn't
notice in my "between pulls" build check, because that is with gcc.

So now it's merged with this error:

   arch/x86/kvm/x86.c:4819:2: error: unannotated fall-through between
switch labels [-Werror,-Wimplicit-fallthrough]

and I'm actually surprised that gcc didn't warn about this too.

We definitely enable -Wimplicit-fallthrough on gcc too, but apparently
it's not functional: falling through to a "break" statement seems to
not warn with gcc. Which is nonsensical, but whatever.

                     Linus

Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

[Nathan Chancellor]

On Fri, Sep 06, 2024 at 03:38:16PM -0700, Linus Torvalds wrote:
> On Fri, 6 Sept 2024 at 08:45, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > - Specialize return value of KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM),
> >   based on VM type
> 
> Grr. This actually causes a build warning with clang, but I didn't
> notice in my "between pulls" build check, because that is with gcc.
> 
> So now it's merged with this error:
> 
>    arch/x86/kvm/x86.c:4819:2: error: unannotated fall-through between
> switch labels [-Werror,-Wimplicit-fallthrough]
> 
> and I'm actually surprised that gcc didn't warn about this too.

Yeah, GCC does not warn when falling through to a break or return, as I
mention in the patch I sent for this (I was going to keep an eye out for
the pull request and comment before it went in but looks like I missed
it):

https://lore.kernel.org/kvm/20240905-kvm-x86-avoid-clang-implicit-fallthrough-v1-1-f2e785f1aa45@kernel.org/

> We definitely enable -Wimplicit-fallthrough on gcc too, but apparently
> it's not functional: falling through to a "break" statement seems to
> not warn with gcc. Which is nonsensical, but whatever.

This was brought up to GCC at one point and they considered its current
behavior as working as intended from my understanding:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432

Cheers,
Nathan

Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

[Linus Torvalds]

On Fri, 6 Sept 2024 at 16:40, Nathan Chancellor <nathan@kernel.org> wrote:
>
> This was brought up to GCC at one point and they considered its current
> behavior as working as intended from my understanding:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432

Their argument seems to be "the missing fallthrough has no effect".

Which is true.

But they seem to be missing that it has no effect *NOW*.

One major problem case is that people tend to add new cases to the end
of a switch() statement, not counting that final "default: break".

So the "it doesn't have any effect NOW" is true, but the next time
somebody edits that and doesn't check warnings, it *will* have very
strange behavior, and it won't be affecting the newly added case, but
some entirely unrelated previous case.

So I really think the lack of warnings is a gcc mis-feature. It leaves
code in a bad situation going forward.

Oh well.  Many times I have had to disable warnings entirely because
they have too many false positives, so I guess the occasional "doesn't
warn enough" is still a better problem to have.

And at least we have (a) clang warning about it and (b) require the
warnings going forward and use -Werror, so at least for the kernel the
"when somebody edits that code, you get surprising behavior" case
_will_ get noticed.

                 Linus