Bug 860929
Summary: | microcode: CPUx: update failed (for patch_level=0x6000624) | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Xu Tian <xutian> | ||||
Component: | qemu-kvm | Assignee: | Eduardo Habkost <ehabkost> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.4 | CC: | acathrow, areis, bsarathy, dyasny, juzhang, mkenneth, virt-maint, xfu | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Known Issue | |||||
Doc Text: |
KVM guests must not be allowed to update the host CPU microcode. KVM does not allows this and instead always returns the same microcode revision or patch level value to the guest. If the guest tries to update the CPU microcode, it will fail and show an error message similar to:
CPU0: update failed (for patch_level=0x6000624)
To work around this, configure the guest to not install CPU microcode updates; for example, uninstall the microcode_ctl package Red Hat Enterprise Linux of Fedora guests.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-10-22 13:36:42 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Xu Tian
2012-09-27 06:25:52 UTC
Created attachment 628706 [details]
dmesg in amd guest
Test packages:
kernel-2.6.32-332.el6 (both guest and host used 332's kernel)
kernel-firmware-2.6.32-323
test with Intel I5-2400 CPU found microcode applied both host and guest
test with AMD Phenom(tm) 8750 CPU, microcode applied on host, but not apply because "not supported"; you can download guest dmesg info attachement;
qemu command line:
qemu-kvm -name 'vm1' -nodefaults -chardev socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121017-175801-SVgS,server,nowait -mon chardev=qmp_monitor_id_qmpmonitor1,mode=control -chardev socket,id=serial_id_20121017-175801-SVgS,path=/tmp/serial-20121017-175801-SVgS,server,nowait -device isa-serial,chardev=serial_id_20121017-175801-SVgS -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 -drive file='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/images/RHEL-Server-6.4-32-virtio.qcow2',if=none,id=drive-virtio-disk1,media=disk,cache=none,boot=off,snapshot=off,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=id7cDCld,mac=9a:fc:22:e3:f6:ae,id=ndev00id7cDCld,bus=pci.0,addr=0x3 -netdev tap,id=id7cDCld,vhost=on,fd=21 -m 2048 -smp 1,cores=0,threads=1,sockets=2 -cpu 'Opteron_G3' -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -vnc :0 -vga cirrus -rtc base=utc,clock=host,driftfix=slew -M rhel6.4.0 -boot order=cdn,once=c,menu=off -no-kvm-pit-reinjection -bios /usr/share/seabios/bios.bin -enable-kvm
thanks,
Xu
(In reply to comment #3) > Created attachment 628706 [details] > dmesg in amd guest > > Test packages: > kernel-2.6.32-332.el6 (both guest and host used 332's kernel) > kernel-firmware-2.6.32-323 > > test with Intel I5-2400 CPU found microcode applied both host and guest > > test with AMD Phenom(tm) 8750 CPU, microcode applied on host, but not apply on guest dmesg show "not supported"; you can download guest dmesg info attachement; > > qemu command line: > qemu-kvm -name 'vm1' -nodefaults -chardev > socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121017- > 175801-SVgS,server,nowait -mon > chardev=qmp_monitor_id_qmpmonitor1,mode=control -chardev > socket,id=serial_id_20121017-175801-SVgS,path=/tmp/serial-20121017-175801- > SVgS,server,nowait -device isa-serial,chardev=serial_id_20121017-175801-SVgS > -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 -drive > file='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/images/ > RHEL-Server-6.4-32-virtio.qcow2',if=none,id=drive-virtio-disk1,media=disk, > cache=none,boot=off,snapshot=off,format=qcow2,aio=native -device > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 > -device > virtio-net-pci,netdev=id7cDCld,mac=9a:fc:22:e3:f6:ae,id=ndev00id7cDCld, > bus=pci.0,addr=0x3 -netdev tap,id=id7cDCld,vhost=on,fd=21 -m 2048 -smp > 1,cores=0,threads=1,sockets=2 -cpu 'Opteron_G3' -device > usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -vnc :0 -vga cirrus -rtc > base=utc,clock=host,driftfix=slew -M rhel6.4.0 -boot > order=cdn,once=c,menu=off -no-kvm-pit-reinjection -bios > /usr/share/seabios/bios.bin -enable-kvm > > thanks, > Xu A microcode update on the virtual CPU doesn't even make sense, the guest shouldn't try to update it. We just return a dummy value on the MSR_IA32_UCODE_REV (== MSR_AMD64_PATCH_LEVEL == 0x0000008b) MSR to make some guests happier. One thing we can consider implementing upstream is to make the patch level value configurable on the QEMU CPU model table, to make a bogus microcode update error message less likely, but that's probably not a feature for RHEL-6. |