Merge branch 'kvm-late-6.1' into HEAD

  32 vCPUs in the shared_info page, KVM does not automatically do so

  and instead requires that KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO be used

  explicitly even when the vcpu_info for a given vCPU resides at the

  "default" location in the shared_info page. This is because KVM is

  not aware of the Xen CPU id which is used as the index into the

  vcpu_info[] array, so cannot know the correct default location.

  "default" location in the shared_info page. This is because KVM may

  not be aware of the Xen CPU id which is used as the index into the

  vcpu_info[] array, so may know the correct default location.

  Note that the shared info page may be constantly written to by KVM;

  it contains the event channel bitmap used to deliver interrupts to

  any vCPU has been running or any event channel interrupts can be

  routed to the guest.

  Setting the gfn to KVM_XEN_INVALID_GFN will disable the shared info

  page.

KVM_XEN_ATTR_TYPE_UPCALL_VECTOR

  Sets the exception vector used to deliver Xen event channel upcalls.

  This is the HVM-wide vector injected directly by the hypervisor

  (not through the local APIC), typically configured by a guest via

  HVM_PARAM_CALLBACK_IRQ.

  HVM_PARAM_CALLBACK_IRQ. This can be disabled again (e.g. for guest

  SHUTDOWN_soft_reset) by setting it to zero.

KVM_XEN_ATTR_TYPE_EVTCHN

  This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates

  support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures

  an outbound port number for interception of EVTCHNOP_send requests

  from the guest. A given sending port number may be directed back

  to a specified vCPU (by APIC ID) / port / priority on the guest,

  or to trigger events on an eventfd. The vCPU and priority can be

  changed by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call,

  but other fields cannot change for a given sending port. A port

  mapping is removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags

  field.

  from the guest. A given sending port number may be directed back to

  a specified vCPU (by APIC ID) / port / priority on the guest, or to

  trigger events on an eventfd. The vCPU and priority can be changed

  by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, but but other

  fields cannot change for a given sending port. A port mapping is

  removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags field. Passing

  KVM_XEN_EVTCHN_RESET in the flags field removes all interception of

  outbound event channels. The values of the flags field are mutually

  exclusive and cannot be combined as a bitmask.

KVM_XEN_ATTR_TYPE_XEN_VERSION

  This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates

  support for KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG. It enables the

  XEN_RUNSTATE_UPDATE flag which allows guest vCPUs to safely read

  other vCPUs' vcpu_runstate_info. Xen guests enable this feature via

  the VM_ASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist

  the VMASST_TYPE_runstate_update_flag of the HYPERVISOR_vm_assist

  hypercall.

4.127 KVM_XEN_HVM_GET_ATTR

  As with the shared_info page for the VM, the corresponding page may be

  dirtied at any time if event channel interrupt delivery is enabled, so

  userspace should always assume that the page is dirty without relying

  on dirty logging.

  on dirty logging. Setting the gpa to KVM_XEN_INVALID_GPA will disable

  the vcpu_info.

KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO

  Sets the guest physical address of an additional pvclock structure

  for a given vCPU. This is typically used for guest vsyscall support.

  Setting the gpa to KVM_XEN_INVALID_GPA will disable the structure.

KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR

  Sets the guest physical address of the vcpu_runstate_info for a given

  vCPU. This is how a Xen guest tracks CPU state such as steal time.

  Setting the gpa to KVM_XEN_INVALID_GPA will disable the runstate area.

KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT

  Sets the runstate (RUNSTATE_running/_runnable/_blocked/_offline) of

  This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates

  support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the

  event channel port/priority for the VIRQ_TIMER of the vCPU, as well

  as allowing a pending timer to be saved/restored.

  as allowing a pending timer to be saved/restored. Setting the timer

  port to zero disables kernel handling of the singleshot timer.

KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR

  This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates

  per-vCPU local APIC upcall vector, configured by a Xen guest with

  the HVMOP_set_evtchn_upcall_vector hypercall. This is typically

  used by Windows guests, and is distinct from the HVM-wide upcall

  vector configured with HVM_PARAM_CALLBACK_IRQ.

  vector configured with HVM_PARAM_CALLBACK_IRQ. It is disabled by

  setting the vector to zero.

4.129 KVM_XEN_VCPU_GET_ATTR

primary storage for certain register types. Therefore, the kernel may use the

values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set.

::

  };

6. Capabilities that can be enabled on vCPUs

============================================

- kvm->slots_lock is taken outside kvm->irq_lock, though acquiring

  them together is quite rare.

- Unlike kvm->slots_lock, kvm->slots_arch_lock is released before

  synchronize_srcu(&kvm->srcu).  Therefore kvm->slots_arch_lock

  can be taken inside a kvm->srcu read-side critical section,

  while kvm->slots_lock cannot.

- kvm->mn_active_invalidate_count ensures that pairs of

  invalidate_range_start() and invalidate_range_end() callbacks

  use the same memslots array.  kvm->slots_lock and kvm->slots_arch_lock

  are taken on the waiting side in install_new_memslots, so MMU notifiers

  must not take either kvm->slots_lock or kvm->slots_arch_lock.

For SRCU:

- ``synchronize_srcu(&kvm->srcu)`` is called _inside_

  the kvm->slots_lock critical section, therefore kvm->slots_lock

  cannot be taken inside a kvm->srcu read-side critical section.

  Instead, kvm->slots_arch_lock is released before the call

  to ``synchronize_srcu()`` and _can_ be taken inside a

  kvm->srcu read-side critical section.

- kvm->lock is taken inside kvm->srcu, therefore

  ``synchronize_srcu(&kvm->srcu)`` cannot be called inside

  a kvm->lock critical section.  If you cannot delay the

  call until after kvm->lock is released, use ``call_srcu``.

On x86:

- vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock

F:	arch/x86/kvm/kvm_onhyperv.*

F:	arch/x86/kvm/svm/hyperv.*

F:	arch/x86/kvm/svm/svm_onhyperv.*

F:	arch/x86/kvm/vmx/evmcs.*

F:	arch/x86/kvm/vmx/hyperv.*

KVM X86 Xen (KVM/Xen)

M:	David Woodhouse <dwmw2@infradead.org>

/* TSC invariant control */

#define HV_X64_MSR_TSC_INVARIANT_CONTROL	0x40000118

/* HV_X64_MSR_TSC_INVARIANT_CONTROL bits */

#define HV_EXPOSE_INVARIANT_TSC		BIT_ULL(0)

/* Register name aliases for temporary compatibility */

#define HV_X64_MSR_STIMER0_COUNT	HV_REGISTER_STIMER0_COUNT

#define HV_X64_MSR_STIMER0_CONFIG	HV_REGISTER_STIMER0_CONFIG

	u64 hv_reenlightenment_control;

	u64 hv_tsc_emulation_control;

	u64 hv_tsc_emulation_status;

	u64 hv_invtsc_control;

	/* How many vCPUs have VP index != vCPU index */

	atomic_t num_mismatched_vp_indexes;

	struct task_struct *nx_huge_page_recovery_thread;

#ifdef CONFIG_X86_64

	/*

	 * Whether the TDP MMU is enabled for this VM. This contains a

	 * snapshot of the TDP MMU module parameter from when the VM was

	 * created and remains unchanged for the life of the VM. If this is

	 * true, TDP MMU handler functions will run for various MMU

	 * operations.

	 */

	bool tdp_mmu_enabled;

	/* The number of TDP MMU pages across all roots. */

	atomic64_t tdp_mmu_pages;

	/*

	 * List of kvm_mmu_page structs being used as roots.

	 * All kvm_mmu_page structs in the list should have

	 * List of struct kvm_mmu_pages being used as roots.

	 * All struct kvm_mmu_pages in the list should have

	 * tdp_mmu_page set.

	 *

	 * For reads, this list is protected by: