When using CPU passthrough the reported CPU microcode version in the guest is hard coded to 0x1:
# cat /proc/cpuinfo
...
processor : 53
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Platinum 8180M CPU @ 2.50GHz
stepping : 4
microcode : 0x1
...
On the host it looks like this:
...
processor : 223
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Platinum 8180M CPU @ 2.50GHz
stepping : 4
microcode : 0x2000064
...
This is a feature request (RFE) to passthrough the host value (0x2000064 in the above example) to the guest (read only). Background information: This would allow the guest to verify to run with a certain microcode version, e.g. if spectre/meltdown fixes are in place.
Discussed with Paolo Bonzini if that would make sense and he agreed.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Verify:
qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae
host kernel: 4.18.0-185.el8.x86_64
guest kernel: 4.18.0-183.el8.x86_64
microcode_ctl-20191115-4.el8.x86_64
Boot guest with '-cpu host', check if microcode version is same between guest and host.
On host,
# cat /proc/cpuinfo | grep micro
microcode : 0x500002c
microcode : 0x500002c
..
Inside guest,
# cat /proc/cpuinfo | grep micro
microcode : 0x500002c
microcode : 0x500002c
..
The microcode version in guest is same to host, so the bug is fixed.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:2017