Hide Forgot
Description of problem: Patch series cover: It turns out that not only do we not follow the SDM guidelines for reseting MTRR state on vCPU reset, but we really don't even attempt to keep KVM MTRR state synchronized with QEMU, which affects not only reset, but migration. This series implements the get/put MSR support for KVM, then goes on to properly re-initialize the state on vCPU reset. This resolves the problem described in the last patch as well as some potential mismatches around migration. The migration state is unchanged, other than actually passing valid data. Required patches: 9db2efd x86: Clear MTRRs on vCPU reset d1ae67f x86: kvm: Add MTRR support for kvm_get|put_msrs() d8b5c67 x86: Use common variable range MTRR counts The issue identified in the last patch is that on an Intel VT-d system where the IOMMU allows snoop control, when using a vfio-pci assigned device and OVMF firmware, the vCPU MTRRs are not cleared on reset and the VM continues to use the settings of the previous guest OS, resulting in an apparent VM hang as the OVMF code takes a full minute to LZMA decompress the firmware volume. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: QE may wish to do regression testing only as the reproduction parameters may be difficult to achieve. Migration testing should be included, as well as assigning a vfio-pci device on either side of the migration.
Do we need to clone this bz to qemu-kvm-rhev component? Best Regards, Junyi
Fix included in qemu-kvm-1.5.3-88.el7
(In reply to Alex Williamson from comment #0) > Additional info: > > QE may wish to do regression testing only as the reproduction parameters may > be difficult to achieve. Migration testing should be included, as well as > assigning a vfio-pci device on either side of the migration. Would you please make the test clear? From what I understand, you meant two kinds of tests: 1. migration regression tests with OVMF 2. before migration hot plug a VF/PF to guest, then hot unplug it and migrate guest, for vfio-pci device is not able to be migrated
(In reply to Chao Yang from comment #5) > (In reply to Alex Williamson from comment #0) > > Additional info: > > > > QE may wish to do regression testing only as the reproduction parameters may > > be difficult to achieve. Migration testing should be included, as well as > > assigning a vfio-pci device on either side of the migration. > > Would you please make the test clear? From what I understand, you meant two > kinds of tests: > 1. migration regression tests with OVMF > 2. before migration hot plug a VF/PF to guest, then hot unplug it and > migrate guest, for vfio-pci device is not able to be migrated Yes, I would do the following with both a seabios and an OVMF VM: 1) cold plug a vfio-pci device, boot the guest 2) reboot the guest and look for any unusual delays in the VM BIOS init 3) hot-unplug the vfio-pci device and migrate the VM 4) reboot the guest on the migration target Thanks
Verified passed as no regression was found with qemu-kvm-1.5.3-101.el7.x86_64 Steps: 1. cold plug a vfio-pci device, boot the guest 2. reboot the guest and look for any unusual delays in the VM BIOS init 3. hot-unplug the vfio-pci device and migrate the VM 4. reboot the guest on the migration target 5. hot plug a vfio-pci device to it and reboot 6. hot-unplug the vfio-pci device and migrate the VM back 7. reboot the guest on the migration target Tests were done with both seabios(seabios-bin-1.7.5-11.el7.noarch) and OVMF(OVMF-20150414-2.gitc9e5618.el7.noarch.rpm), neither observed abnormal behaviour during firmware initialization. CLI: /usr/libexec/qemu-kvm -S -name test -m 4G -realtime mlock=on -smp 4,sockets=2,cores=2,threads=1 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0 -drive file=/mnt/rhel7.2.copy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -netdev tap,id=idinWyYp,vhost=on -device virtio-net-pci,mac=42:ce:a9:d1:4d:d5,id=idlbq7eA,netdev=idinWyYp -device usb-tablet,id=input0 -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -spice port=8000,disable-ticketing -msg timestamp=on -monitor stdio -device vfio-pci,host=0000:05:00.0,id=pf Per above, this issue has fixed.
According to comment7, set this issue as verified.
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://rhn.redhat.com/errata/RHBA-2015-2213.html