Skip to content
  1. Dec 23, 2020
  3. Dec 03, 2020
  5. Nov 08, 2020
  7. Oct 28, 2020
  9. Oct 21, 2020
  11. Oct 16, 2020
  13. Oct 05, 2020
  15. Oct 02, 2020
  17. Sep 29, 2020
  19. Sep 28, 2020
    • Alexander Graf's avatar
      KVM: x86: Introduce MSR filtering · 1a155254
      Alexander Graf authored 
      

It's not desireable to have all MSRs always handled by KVM kernel space. Some
MSRs would be useful to handle in user space to either emulate behavior (like
uCode updates) or differentiate whether they are valid based on the CPU model.

To allow user space to specify which MSRs it wants to see handled by KVM,
this patch introduces a new ioctl to push filter rules with bitmaps into
KVM. Based on these bitmaps, KVM can then decide whether to reject MSR access.
With the addition of KVM_CAP_X86_USER_SPACE_MSR it can also deflect the
denied MSR events to user space to operate on.

If no filter is populated, MSR handling stays identical to before.

Signed-off-by: default avatarAlexander Graf <graf@amazon.com>

Message-Id: <20200925143422.21718-8-graf@amazon.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1a155254
    • Alexander Graf's avatar
      KVM: x86: Allow deflecting unknown MSR accesses to user space · 1ae09954
      Alexander Graf authored 
      

MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again are really just windows into package configuration.

Out of these MSRs, only the first category is necessary to implement in
kernel space. Rarely accessed MSRs, MSRs that should be fine tunes against
certain CPU models and MSRs that contain information on the package level
are much better suited for user space to process. However, over time we have
accumulated a lot of MSRs that are not the first category, but still handled
by in-kernel KVM code.

This patch adds a generic interface to handle WRMSR and RDMSR from user
space. With this, any future MSR that is part of the latter categories can
be handled in user space.

Furthermore, it allows us to replace the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.

Signed-off-by: default avatarAlexander Graf <graf@amazon.com>
Reviewed-by: default avatarJim Mattson <jmattson@google.com>

Message-Id: <20200925143422.21718-3-graf@amazon.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1ae09954
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Mention SynDBG CPUID leaves in api.rst · b44f50d8
      Vitaly Kuznetsov authored 
      

We forgot to update KVM_GET_SUPPORTED_HV_CPUID's documentation in api.rst
when SynDBG leaves were added.

While on it, fix 'KVM_GET_SUPPORTED_CPUID' copy-paste error.

Fixes: f97f5a56 ("x86/kvm/hyper-v: Add support for synthetic debugger interface")
Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200924145757.1035782-2-vkuznets@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b44f50d8
  21. Sep 24, 2020
  23. Sep 22, 2020
  25. Sep 14, 2020
  27. Sep 11, 2020
  29. Sep 10, 2020
  31. Sep 09, 2020
  33. Aug 21, 2020
  35. Jul 22, 2020
  37. Jul 13, 2020
  39. Jul 10, 2020
  41. Jul 08, 2020
  43. Jul 05, 2020
  45. Jun 01, 2020
    • Jon Doron's avatar
      x86/kvm/hyper-v: Add support for synthetic debugger interface · f97f5a56
      Jon Doron authored 
      

Add support for Hyper-V synthetic debugger (syndbg) interface.
The syndbg interface is using MSRs to emulate a way to send/recv packets
data.

The debug transport dll (kdvm/kdnet) will identify if Hyper-V is enabled
and if it supports the synthetic debugger interface it will attempt to
use it, instead of trying to initialize a network adapter.

Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: default avatarJon Doron <arilou@gmail.com>
Message-Id: <20200529134543.1127440-4-arilou@gmail.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f97f5a56
    • Peter Shier's avatar
      KVM: nVMX: Fix VMX preemption timer migration · 850448f3
      Peter Shier authored 
      

Add new field to hold preemption timer expiration deadline
appended to struct kvm_vmx_nested_state_hdr. This is to prevent
the first VM-Enter after migration from incorrectly restarting the timer
with the full timer value instead of partially decayed timer value.
KVM_SET_NESTED_STATE restarts timer using migrated state regardless
of whether L1 sets VM_EXIT_SAVE_VMX_PREEMPTION_TIMER.

Fixes: cf8b84f4 ("kvm: nVMX: Prepare for checkpointing L2 state")

Signed-off-by: default avatarPeter Shier <pshier@google.com>
Signed-off-by: default avatarMakarand Sonare <makarandsonare@google.com>
Message-Id: <20200526215107.205814-2-makarandsonare@google.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      850448f3
    • Jon Doron's avatar
      x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit · f7d31e65
      Jon Doron authored 
      

The problem the patch is trying to address is the fact that 'struct
kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
modes.

In 64-bit mode the default alignment boundary is 64 bits thus
forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
boundary is at 32 bits thus no extra gaps.

This is an issue as even when the kernel is 64 bit, the userspace using
the interface can be both 32 and 64 bit but the same 32 bit userspace has
to work with 32 bit kernel.

The issue is fixed by forcing the 64 bit layout, this leads to ABI
change for 32 bit builds and while we are obviously breaking '32 bit
userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
with 64 bit kernel' one.

As the interface has no (known) users and 32 bit KVM is rather baroque
nowadays, this seems like a reasonable decision.

Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: default avatarJon Doron <arilou@gmail.com>
Message-Id: <20200424113746.3473563-2-arilou@gmail.com>
Reviewed-by: default avatarRoman Kagan <rvkagan@yandex-team.ru>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f7d31e65
    • Vitaly Kuznetsov's avatar
      KVM: x86: announce KVM_FEATURE_ASYNC_PF_INT · 72de5fa4
      Vitaly Kuznetsov authored 
      

Introduce new capability to indicate that KVM supports interrupt based
delivery of 'page ready' APF events. This includes support for both
MSR_KVM_ASYNC_PF_INT and MSR_KVM_ASYNC_PF_ACK.

Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200525144125.143875-8-vkuznets@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      72de5fa4
    • Vitaly Kuznetsov's avatar
      KVM: x86: acknowledgment mechanism for async pf page ready notifications · 557a961a
      Vitaly Kuznetsov authored 
      

If two page ready notifications happen back to back the second one is not
delivered and the only mechanism we currently have is
kvm_check_async_pf_completion() check in vcpu_run() loop. The check will
only be performed with the next vmexit when it happens and in some cases
it may take a while. With interrupt based page ready notification delivery
the situation is even worse: unlike exceptions, interrupts are not handled
immediately so we must check if the slot is empty. This is slow and
unnecessary. Introduce dedicated MSR_KVM_ASYNC_PF_ACK MSR to communicate
the fact that the slot is free and host should check its notification
queue. Mandate using it for interrupt based 'page ready' APF event
delivery.

As kvm_check_async_pf_completion() is going away from vcpu_run() we need
a way to communicate the fact that vcpu->async_pf.done queue has
transitioned from empty to non-empty state. Introduce
kvm_arch_async_page_present_queued() and KVM_REQ_APF_READY to do the job.

Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200525144125.143875-7-vkuznets@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      557a961a