tree b93b0c3e721d189bd335bafade05d94833c6a54a
parent aa739dafa6bfa42b35c013ff020e9d49ebc1a9ff
author Vitaly Kuznetsov <vkuznets@redhat.com> 1611856891 -0500
committer Chromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com> 1652142524 +0000

BACKPORT: UPSTREAM: KVM: Raise the maximum number of user memslots

Current KVM_USER_MEM_SLOTS limits are arch specific (512 on Power, 509 on x86,
32 on s390, 16 on MIPS) but they don't really need to be. Memory slots are
allocated dynamically in KVM when added so the only real limitation is
'id_to_index' array which is 'short'. We don't have any other
KVM_MEM_SLOTS_NUM/KVM_USER_MEM_SLOTS-sized statically defined structures.

Low KVM_USER_MEM_SLOTS can be a limiting factor for some configurations.
In particular, when QEMU tries to start a Windows guest with Hyper-V SynIC
enabled and e.g. 256 vCPUs the limit is hit as SynIC requires two pages per
vCPU and the guest is free to pick any GFN for each of them, this fragments
memslots as QEMU wants to have a separate memslot for each of these pages
(which are supposed to act as 'overlay' pages).

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210127175731.2020089-3-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry-picked from commit 4fc096a99e01dd06dc55bef76ade7f8d76653245)

Conflicts:
    arch/mips/include/asm/kvm_host.h - kept original KVM_MAX_VCPUS 8
    instead of patch's 16 from v5.x kernel.

BUG=b:219086168
BUG=b:207515789
TEST=emerge chromeos-kernel-4_19

Change-Id: Ic67c513c43f1a9c7d2fd19b2168d9f41c9e56af4
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3620960
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>