4901314d0d
As explained in QEMU commit 4c257911dcc7c4189768e9651755c849ce9db4e8 intel-pt features should never be included in the CPU models as it was not supported by KVM back then and even once it started to be supported, users have to enable it by passing pt_mode=1 parameter to kvm_intel module. The Icelake-* CPU models with intel-pt included were added to QEMU 3.1.0 and removed right in the following 4.0.0 release (and even in 3.1.1 maintenance release). In libvirt 6.10.0 I introduced 'removed' attribute for features included in our CPU model definitions which we can use to drop intel-pt from Icelake-* CPU models. Back then I explained we can safely do so only for features which could never be enabled, which is not the case of intel-pt. Theoretically, it could be possible to create an environment in which QEMU would enable intel-pt without asking for it explicitly: it would need to use a new enough kernel (not available at the time of QEMU 3.1.0) and pt_mode KVM parameter in combination with QEMU 3.1.0 running a domain with q35 machine type and all that on a CPU which didn't really exist at that time. Migrating such domain to a host with newer SW stack including libvirt with this patch applied would result in incompatible guest ABI (the virtual CPU would lose intel-pt). However, QEMU changed its CPU models unconditionally and thus migration would not work even without this patch. That said, it is safe to follow QEMU and remove the feature from Icelake-* CPU models in our cpu_map. https://bugzilla.redhat.com/show_bug.cgi?id=1853972 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Libvirt API for virtualization
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the website:
License
The libvirt C API is distributed under the terms of GNU Lesser
General Public License, version 2.1 (or later). Some parts of the code
that are not part of the C library may have the more restrictive GNU
General Public License, version 2.0 (or later). See the files
COPYING.LESSER and COPYING for full license
terms & conditions.
Installation
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
The libvirt project has two primary mailing lists:
- libvirt-users@redhat.com (for user discussions)
- libvir-list@redhat.com (for development only)
Further details on contacting the project are available on the website: