linux-stable.git/include/linux/kvm_host.h, branch v5.6.2

KVM: let declaration of kvm_get_running_vcpus match implementation

2020-02-28T09:33:57+00:00

Sparse notices that declaration and implementation do not match:
arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17: warning: incorrect type in return expression (different address spaces)
arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17:    expected struct kvm_vcpu [noderef]  **
arch/s390/kvm/../../../virt/kvm/kvm_main.c:4435:17:    got struct kvm_vcpu *[noderef]  *

Signed-off-by: Christian Borntraeger 
Signed-off-by: Paolo Bonzini

KVM: x86: fix missing prototypes

2020-02-17T11:52:38+00:00

Reported with "make W=1" due to -Wmissing-prototypes.

Reported-by: Qian Cai 
Reviewed-by: Miaohe Lin 
Signed-off-by: Paolo Bonzini

Merge branch 'cve-2019-3016' into kvm-next-5.6

2020-01-30T17:47:59+00:00

From Boris Ostrovsky:

The KVM hypervisor may provide a guest with ability to defer remote TLB
flush when the remote VCPU is not running. When this feature is used,
the TLB flush will happen only when the remote VPCU is scheduled to run
again. This will avoid unnecessary (and expensive) IPIs.

Under certain circumstances, when a guest initiates such deferred action,
the hypervisor may miss the request. It is also possible that the guest
may mistakenly assume that it has already marked remote VCPU as needing
a flush when in fact that request had already been processed by the
hypervisor. In both cases this will result in an invalid translation
being present in a vCPU, potentially allowing accesses to memory locations
in that guest's address space that should not be accessible.

Note that only intra-guest memory is vulnerable.

The five patches address both of these problems:
1. The first patch makes sure the hypervisor doesn't accidentally clear
a guest's remote flush request
2. The rest of the patches prevent the race between hypervisor
acknowledging a remote flush request and guest issuing a new one.

Conflicts:
	arch/x86/kvm/x86.c [move from kvm_arch_vcpu_free to kvm_arch_vcpu_destroy]

x86/kvm: Cache gfn to pfn translation

2020-01-30T17:45:55+00:00

__kvm_map_gfn()'s call to gfn_to_pfn_memslot() is
* relatively expensive
* in certain cases (such as when done from atomic context) cannot be called

Stashing gfn-to-pfn mapping should help with both cases.

This is part of CVE-2019-3016.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Joao Martins 
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini

x86/kvm: Introduce kvm_(un)map_gfn()

2020-01-30T17:45:54+00:00

kvm_vcpu_(un)map operates on gfns from any current address space.
In certain cases we want to make sure we are not mapping SMRAM
and for that we can use kvm_(un)map_gfn() that we are introducing
in this patch.

This is part of CVE-2019-3016.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Joao Martins 
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini

KVM: Use vcpu-specific gva->hva translation when querying host page size

2020-01-27T19:00:02+00:00

Use kvm_vcpu_gfn_to_hva() when retrieving the host page size so that the
correct set of memslots is used when handling x86 page faults in SMM.

Fixes: 54bf36aac520 ("KVM: x86: use vcpu-specific functions to read/write/translate GFNs")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson 
Signed-off-by: Paolo Bonzini

mm: thp: KVM: Explicitly check for THP when populating secondary MMU

2020-01-27T19:00:01+00:00

Add a helper, is_transparent_hugepage(), to explicitly check whether a
compound page is a THP and use it when populating KVM's secondary MMU.
The explicit check fixes a bug where a remapped compound page, e.g. for
an XDP Rx socket, is mapped into a KVM guest and is mistaken for a THP,
which results in KVM incorrectly creating a huge page in its secondary
MMU.

Fixes: 936a5fe6e6148 ("thp: kvm mmu transparent hugepage support")
Reported-by: syzbot+c9d1fb51ac9d0d10c39d@syzkaller.appspotmail.com
Cc: Andrea Arcangeli 
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson 
Signed-off-by: Paolo Bonzini

KVM: Move running VCPU from ARM to common code

2020-01-27T18:59:54+00:00

For ring-based dirty log tracking, it will be more efficient to account
writes during schedule-out or schedule-in to the currently running VCPU.
We would like to do it even if the write doesn't use the current VCPU's
address space, as is the case for cached writes (see commit 4e335d9e7ddb,
"Revert "KVM: Support vCPU-based gfn->hva cache"", 2017-05-02).

Therefore, add a mechanism to track the currently-loaded kvm_vcpu struct.
There is already something similar in KVM/ARM; one important difference
is that kvm_arch_vcpu_{load,put} have two callers in virt/kvm/kvm_main.c:
we have to update both the architecture-independent vcpu_{load,put} and
the preempt notifiers.

Another change made in the process is to allow using kvm_get_running_vcpu()
in preemptible code.  This is allowed because preempt notifiers ensure
that the value does not change even after the VCPU thread is migrated.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Paolo Bonzini 
Signed-off-by: Peter Xu 
Signed-off-by: Paolo Bonzini

KVM: Remove kvm_read_guest_atomic()

2020-01-27T18:59:51+00:00

Remove kvm_read_guest_atomic() because it's not used anywhere.

Signed-off-by: Peter Xu 
Signed-off-by: Paolo Bonzini

KVM: Drop kvm_arch_vcpu_init() and kvm_arch_vcpu_uninit()

2020-01-27T18:59:33+00:00

Remove kvm_arch_vcpu_init() and kvm_arch_vcpu_uninit() now that all
arch specific implementations are nops.

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