Bug 2095260

+++ This bug was initially created as a clone of Bug #2094270 +++

Description of problem:
In downstream qemu-kvm, we have a patch ("globally limit the maximum number of CPUs") that sets the hard limit of possible vCPUs to the value that the KVM code of the kernel recommends as soft limit. This soft limit was set to a value that we've tested in our downstream RHEL releases, so it make sense to set the hard limit to the same value. However, in upstream, the code has been changed recently to not use an arbitrary soft limit here anymore, but to cap the value on the amount of available physical CPUs of the host. So if that patch gets backported to the downstream kernel (see BZ 2074832), the hack in qemu-kvm won't work as expected anymore, making it impossible to set a "-smp x" value for the guests where x is greater than the amount of available physical CPUs.

Version-Release number of selected component (if applicable):
qemu-kvm-7.0.0-4.el9

How reproducible:
100%

Steps to Reproduce:
1. Install an upstream kernel (or the one from BZ 2074832)
2. Run a guest with more vCPUs than available physical host CPUs, e.g.:
   /usr/libexec/qemu-kvm -smp 700

Actual results:
qemu-kvm will refuse to start.

Expected results:
qemu-kvm should still run the guest.

Additional info:
I think we should simply revert/drop the "globally limit the maximum number of CPUs" patch in downstream qemu-kvm now.

[...]
--- Additional comment from Chao Yang on 2022-06-09 04:28:43 CEST ---

Do we need a counterpart libvirt bz in case we try migrating a VM with vCPU number exceeds the pCPU number of the destination host?

[...]
--- Additional comment from Jiri Denemark on 2022-06-09 13:16:54 CEST ---

I think we actually need libvirt bz to revert
https://gitlab.com/redhat/rhel/src/libvirt/-/commit/fcec98bb80633bec6f4bc3de0ab75627c874d315
RHEL-only patch. We are not involved in limit checking, but we report the
maximum number of virtual CPUs.