linux-stable.git/include/linux/kvm_host.h, branch v4.18.2

kvm: Make VM ioctl do valloc for some archs

2018-06-01T17:18:26+00:00

The kvm struct has been bloating. For example, it's tens of kilo-bytes
for x86, which turns out to be a large amount of memory to allocate
contiguously via kzalloc. Thus, this patch does the following:
1. Uses architecture-specific routines to allocate the kvm struct via
   vzalloc for x86.
2. Switches arm to __KVM_HAVE_ARCH_VM_ALLOC so that it can use vzalloc
   when has_vhe() is true.

Other architectures continue to default to kalloc, as they have a
dependency on kalloc or have a small-enough struct kvm.

Signed-off-by: Marc Orr 
Reviewed-by: Marc Zyngier 
Signed-off-by: Paolo Bonzini

kvm: Change return type to vm_fault_t

2018-06-01T17:18:25+00:00

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
Signed-off-by: Paolo Bonzini

Merge tag 'kvmarm-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

2018-06-01T17:17:22+00:00

KVM/ARM updates for 4.18

- Lazy context-switching of FPSIMD registers on arm64
- Allow virtual redistributors to be part of two or more MMIO ranges

KVM: introduce kvm_make_vcpus_request_mask() API

2018-05-26T12:14:33+00:00

Hyper-V style PV TLB flush hypercalls inmplementation will use this API.
To avoid memory allocation in CONFIG_CPUMASK_OFFSTACK case add
cpumask_var_t argument.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Radim Krčmář

KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change

2018-05-25T11:27:54+00:00

KVM/ARM differs from other architectures in having to maintain an
additional virtual address space from that of the host and the
guest, because we split the execution of KVM across both EL1 and
EL2.

This results in a need to explicitly map data structures into EL2
(hyp) which are accessed from the hyp code.  As we are about to be
more clever with our FPSIMD handling on arm64, which stores data in
the task struct and uses thread_info flags, we will have to map
parts of the currently executing task struct into the EL2 virtual
address space.

However, we don't want to do this on every KVM_RUN, because it is a
fairly expensive operation to walk the page tables, and the common
execution mode is to map a single thread to a VCPU.  By introducing
a hook that architectures can select with
HAVE_KVM_VCPU_RUN_PID_CHANGE, we do not introduce overhead for
other architectures, but have a simple way to only map the data we
need when required for arm64.

This patch introduces the framework only, and wires it up in the
arm/arm64 KVM common code.

No functional change.

Signed-off-by: Christoffer Dall 
Signed-off-by: Dave Martin 
Reviewed-by: Marc Zyngier 
Reviewed-by: Alex Bennée 
Signed-off-by: Marc Zyngier

KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

2018-05-11T09:21:10+00:00

Our virtual machines make use of device assignment by configuring
12 NVMe disks for high I/O performance. Each NVMe device has 129
MSI-X Table entries:
Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 offset=00002000
The windows virtual machines fail to boot since they will map the number of
MSI-table entries that the NVMe hardware reported to the bus to msi routing
table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096
for all archs, in the future this might be extended again if needed.

Reviewed-by: Cornelia Huck 
Cc: Paolo Bonzini 
Cc: Radim KrÄmÃ¡Å™ 
Cc: Cornelia Huck 
Cc: Christian Borntraeger 
Signed-off-by: Wanpeng Li 
Signed-off-by: Tonny Lu 
Signed-off-by: Paolo Bonzini

kvm: fix warning for non-x86 builds

2018-02-24T00:43:47+00:00

Fix the following sparse warning by moving the prototype
of kvm_arch_mmu_notifier_invalidate_range() to linux/kvm_host.h .

  CHECK   arch/s390/kvm/../../../virt/kvm/kvm_main.c
arch/s390/kvm/../../../virt/kvm/kvm_main.c:138:13: warning: symbol 'kvm_arch_mmu_notifier_invalidate_range' was not declared. Should it be static?

Signed-off-by: Sebastian Ott 
Signed-off-by: Paolo Bonzini

kvm: fix warning for CONFIG_HAVE_KVM_EVENTFD builds

2018-02-24T00:43:46+00:00

Move the kvm_arch_irq_routing_update() prototype outside of
ifdef CONFIG_HAVE_KVM_EVENTFD guards to fix the following sparse warning:

arch/s390/kvm/../../../virt/kvm/irqchip.c:171:28: warning: symbol 'kvm_arch_irq_routing_update' was not declared. Should it be static?

Signed-off-by: Sebastian Ott 
Acked-by: Christian Borntraeger 
Signed-off-by: Paolo Bonzini

KVM: introduce kvm_arch_vcpu_async_ioctl

2017-12-14T08:26:59+00:00

After the vcpu_load/vcpu_put pushdown, the handling of asynchronous VCPU
ioctl is already much clearer in that it is obvious that they bypass
vcpu_load and vcpu_put.

However, it is still not perfect in that the different state of the VCPU
mutex is still hidden in the caller.  Separate those ioctls into a new
function kvm_arch_vcpu_async_ioctl that returns -ENOIOCTLCMD for more
"traditional" synchronous ioctls.

Cc: James Hogan 
Cc: Paul Mackerras 
Cc: Christian Borntraeger 
Reviewed-by: Christoffer Dall 
Reviewed-by: Cornelia Huck 
Suggested-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini

KVM: Take vcpu->mutex outside vcpu_load

2017-12-14T08:26:49+00:00

As we're about to call vcpu_load() from architecture-specific
implementations of the KVM vcpu ioctls, but yet we access data
structures protected by the vcpu->mutex in the generic code, factor
this logic out from vcpu_load().

x86 is the only architecture which calls vcpu_load() outside of the main
vcpu ioctl function, and these calls will no longer take the vcpu mutex
following this patch.  However, with the exception of
kvm_arch_vcpu_postcreate (see below), the callers are either in the
creation or destruction path of the VCPU, which means there cannot be
any concurrent access to the data structure, because the file descriptor
is not yet accessible, or is already gone.

kvm_arch_vcpu_postcreate makes the newly created vcpu potentially
accessible by other in-kernel threads through the kvm->vcpus array, and
we therefore take the vcpu mutex in this case directly.

Signed-off-by: Christoffer Dall 
Reviewed-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini