Bug 1500181 - [Q35] guest boot up failed with ovmf
Summary: [Q35] guest boot up failed with ovmf
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: jingzhao
URL:
Whiteboard:
Keywords: TestOnly
Depends On: ovmf-rebase-rhel-7.5 1489800 1499011
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-10 07:05 UTC by jingzhao
Modified: 2018-04-11 00:40 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-11 00:38:42 UTC


Attachments (Terms of Use)
ovmf log (1009.01 KB, text/plain)
2017-10-10 07:05 UTC, jingzhao
no flags Details
screenshot of boot up (16.05 KB, image/png)
2017-10-10 07:08 UTC, jingzhao
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1104 None None None 2018-04-11 00:40 UTC

Description jingzhao 2017-10-10 07:05:54 UTC
Created attachment 1336655 [details]
ovmf log

Description of problem:
guest boot up failed with ovmf 

Version-Release number of selected component (if applicable):
[root@dell-per730-29 jing]# rpm -qa |grep qemu-kvm-rhev
qemu-kvm-rhev-2.10.0-1.el7.x86_64
qemu-kvm-rhev-debuginfo-2.10.0-1.el7.x86_64
[root@dell-per730-29 jing]# uname -r
3.10.0-731.el7.x86_64
[root@dell-per730-29 jing]# rpm -qa |grep OVMF
OVMF-20170228-5.gitc325e41585e3.el7.noarch


How reproducible:
3/3

Steps to Reproduce:
1. Boot up guest with qemu command line [1]
2. Check the guest 

Actual results:
guest boot up failed

Expected results:
guest boot up successfully

Additional info:
ovmf log, please check the attachment

[1]
/usr/libexec/qemu-kvm \
-machine q35,smm=on,accel=kvm \
-cpu Haswell-noTSX \
-nodefaults -rtc base=utc \
-m 4G \
-smp 4,sockets=4,cores=1,threads=1 \
-enable-kvm \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-k en-us \
-nodefaults \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/home/jing/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-serial unix:/tmp/serial0,server,nowait \
-debugcon file:/home/jing/ovmf.log \
-global isa-debugcon.iobase=0x402 \
-boot menu=on \
-qmp tcp:0:6667,server,nowait \
-usb \
-device usb-tablet \
-vga qxl \
-global driver=cfi.pflash01,property=secure,value=on \
-drive file=/home/jing/ovmf-win2016.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=0 \
-device pcie-root-port,bus=pcie.0,id=root0,multifunction=on,chassis=1,addr=0xa.0 \
-device virtio-net-pci,netdev=tap10,mac=9a:6a:6b:6c:6d:6e,bus=root0 -netdev tap,id=tap10 \
-device pcie-root-port,bus=pcie.0,id=root1,chassis=11,addr=0xa.1 \
-device pcie-root-port,bus=pcie.0,id=root2,chassis=12,addr=0xa.2 \
-device pcie-root-port,bus=pcie.0,id=root3 \
-cdrom /home/jing/en_windows_server_2016_x64_dvd_9718492.iso \
-device ahci,id=ahci0 \
-drive file=/usr/share/virtio-win/virtio-win-1.9.3.iso,if=none,id=drive-virtio-disk1,format=raw \
-device ide-cd,drive=drive-virtio-disk1,id=virtio-disk1,bus=ahci0.0 \
-monitor stdio \
-vnc :1 \

Comment 2 jingzhao 2017-10-10 07:08 UTC
Created attachment 1336656 [details]
screenshot of boot up

Comment 3 jingzhao 2017-10-10 07:09:42 UTC
guest can boot up successfully on qemu-kvm-rhev-2.9.0-16.el7_4.9.x86_64.rpm &
OVMF-20170228-5.gitc325e41585e3.el7.noarch

Comment 4 Laszlo Ersek 2017-10-10 19:28:31 UTC
(CC Dave)

Hi Jing Zhao,

given that "OVMF-20170228-5.gitc325e41585e3.el7.noarch" works on

  qemu-kvm-rhev-2.9.0-16.el7_4.9.x86_64

and that the same fails on

  qemu-kvm-rhev-2.10.0-1.el7.x86_64

I think that you are hitting a known incompatibility between QEMU 2.10 and
"old" OVMF.

The fix for that is going to be three-fold:

* For bug 1499011, Dave is working on the "pc-q35-rhel7.5.0" machine type.

* For bug 1469787, I'll soon rebase OVMF to current upstream edk2.

  Upstream OVMF runs fine on QEMU 2.10, hence the rebased OVMF will run OK
  on qemu-kvm-rhev-2.10.0 too, using the most recent Q35 downstream machine
  type (i.e., pc-q35-rhel7.5.0).

* For bug 1489800, Dave has fixes for older machine types, so that
  OVMF-20170228-5.gitc325e41585e3.el7.noarch will run fine on
  qemu-kvm-rhev-2.10.0, using machine type "pc-q35-rhel7.4.0".

I suggest:

(a) either closing this BZ as a duplicate of one of the above three BZs,

(b) or marking this BZ TestOnly, and making it dependent on all three of the
    above BZs.

Comment 9 Laszlo Ersek 2017-10-20 09:57:42 UTC
All pre-requisite BZs are now at least in MODIFIED state, so bumping this as well, so QE can start testing when they wish so.

Comment 10 jingzhao 2017-10-24 03:16:04 UTC
Verified it on qemu-kvm-rhev-2.10.0-3.el7.x86_64 & OVMF-20171011-1.git92d07e48907f.el7.noarch, guest can boot up successfully

According to above test result, changed to verified

Comment 12 errata-xmlrpc 2018-04-11 00:38:42 UTC
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/RHSA-2018:1104


Note You need to log in before you can comment on or make changes to this bug.