Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1700248[details]
libvirtd.log
Reproduced on rhel8.3 slow train.
libvirt-client-6.0.0-25.module+el8.3.0+7176+57f10f42.x86_64
qemu-kvm-4.2.0-30.module+el8.3.0+7298+c26a06b8
kernel-4.18.0-222.el8.x86_64
+++ This bug was initially created as a clone of Bug #1853972 +++
Description of problem:
Enable intel-pt on host, boot guest with cpu mode=host-model, flag intel-pt is not added into qemu cli.
Version-Release number of selected component (if applicable):
qemu-kvm-4.2.0-28.module+el8.2.1+7211+16dfe810
libvirt-client-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64
kernel-4.18.0-193.11.1.el8_2.x86_64
How reproducible:
always
Steps to Reproduce:
1. Set pt_mode = 1 on Icelake host first,
# rmmod kvm_intel
# modprobe kvm_intel pt_mode=1
2. Boot guest with libvirt cpu mode=host-model
<cpu mode='host-model'/>
3. Check qemu cli
Actual results:
Flag intel-pt is not in qemu cli:
-machine pc-q35-rhel8.2.0,accel=kvm,usb=off,dump-guest-core=off \
-cpu Icelake-Server,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,avx512ifma=on,sha-ni=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,ibpb=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,mpx=off,hv-time,hv-vapic,hv-spinlocks=0x1000
Expected results:
Option "intel-pt=on" should be added into qemu cli.
Additional info:
Reproduce with both pc and q35 machine type.
--- Additional comment from Yumei Huang on 2020-07-06 10:40:47 CST ---
Add Regression keyword since the test passed before in https://bugzilla.redhat.com/show_bug.cgi?id=1526581#c7.
--- Additional comment from Eduardo Habkost on 2020-07-07 03:10:46 CST ---
We need more information on what information QEMU is returning through QMP, to know where exactly is the problem.
I suggest the following:
1) adding the following to the /etc/libvirt/libvirtd.conf:
log_filters="1:libvirt 1:util 1:qemu"
log_outputs="1:file:/var/log/libvirt/libvirtd.log"
2) delete /var/cache/libvirt/qemu/capabilities/*
3) restart libvirtd
4) reproduce the bug
5) Run:
# grep QEMU_MONITOR /var/log/libvirt/libvirtd.log | grep -3 query-cpu-model-expansion
Please also attach /var/log/libvirt/libvirtd.log to the BZ, just in case there's other information useful for debugging the problem.
--- Additional comment from Eduardo Habkost on 2020-07-07 03:13:12 CST ---
There's a missing step in the instructions below:
(In reply to Eduardo Habkost from comment #2)
[...]
> 2) delete /var/cache/libvirt/qemu/capabilities/*
2.1) reload kvm_intel with pt_mode=1
# rmmod kvm_intel
# modprobe kvm_intel pt_mode=1
>
> 3) restart libvirtd
[...]
Maybe we are dealing with two separate issues here: intel_pt not being enabled in some circumstances, and also lack of invalidation of QEMU capabilities cache when the kernel command line or kvm module arguments change.
As already mentioned by Eduardo, there are two separate issues here:
(1) changing kvm* module parameters does not invalidate QEMU capabilities
cache in libvirt and thus libvirt does not know intel-pt becomes available
(2) intel-pt is not enabled by host-model on an Icelake-Server host
I created a separate bug 1879200 for the first issue. So let's focus on the
second one here as it also matches the summary.
Because the definition of Icelake-Server in libvirt contains intel-pt (copied
from QEMU before intel-pt was removed from all models), we do not include the
feature in host-model. We think QEMU will enable it automatically when asked
for Icelake-Server.
When intel-pt is explicitly requested:
<cpu mode='host-model'>
<feature name='intel-pt' policy='require'/>
</cpu>
or
<cpu mode='custom' match='exact'>
<model fallback='forbid'>Icelake-Server</model>
<feature name='intel-pt' policy='require'/>
</cpu>
libvirt will ask QEMU for intel-pt even though it thinks the feature would be
enabled implicitly. That said, intel-pt is still usable, it is just not
enabled by default for host-model on an Icelake-Server host.
To fix this, we would need to change the definition of Icelake-Server model
and remove intel-pt from it. We did remove some features in the past, but only
when there was no way a domain using such feature could ever be started. By
removing a feature from a CPU model definition, we can end up with mismatching
definitions during migration when migrating from new to old libvirt or the
opposite direction.
Unfortunately in this specific case changing Icelake-Server CPU model would
result in broken migration in several cases and mostly when intel-pt was not
actually enabled. Specifically, in the default case of pt_mode=0 migration
from new libvirt (with updated Icelake-Server CPU model) to older libvirt
would fail for both custom and host-model mode unless intel-pt was explicitly
mentioned in domain XML. The older libvirt would think the original domain was
started with intel-pt enabled while it would be disabled on the destination.
Migration from new to old libvirt would also fail (for the same reason) when
pt_mode=1 on the source using custom CPU mode and Icelake-Server model unless
intel-pt was explicitly mentioned in domain XML. Migrating a domain with
host-model CPU would work fine in this case (i.e., it would correctly either
work or fail depending on pt_mode settings on the destination host and machine
type).
That said, I don't think we can fix this by modifying the Icelake-Server CPU
model. Unless we can be sure there are no Icelake-Server CPUs in production.
An ideal solution would be using CPU model definitions from QEMU when building
host-model CPU definition to make sure the result matches exactly what QEMU
could enable on the host. But AFAIK QEMU does not currently provide any
interface we could use to probe all CPU model definitions with -machine none.