Comment 30 for bug 1725560

Thanks everyone for the investigation thus far.

I cannot reproduce the issue (using an IDE CD-ROM):

* QEMU: tested both the v2.10.1 release, and current upstream master
  (3d7196d43bfe, "Merge remote-tracking branch
  'remotes/kraxel/tags/usb-20171023-pull-request' into staging", 2017-10-24)

* OVMF: built from current upstream master (704b71d7e11f,
  "MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of
  SMM", 2017-10-10)

QEMU script:

> ISO=/mnt/data/isos/iso-windows/en_windows_10_enterprise_2015_ltsb_n_x64_dvd_6848316.iso
> CODE=/home/virt-images/OVMF_CODE.4m.fd
> TMPL=/home/virt-images/OVMF_VARS.4m.fd
>
> cp $TMPL vars18.fd
>
> /opt/qemu-installed/bin/qemu-system-x86_64 \
> -m 2048 \
> -M q35 \
> -enable-kvm \
> -device qxl-vga \
> -drive if=pflash,readonly,format=raw,file=$CODE \
> -drive if=pflash,format=raw,file=vars18.fd \
> -drive id=cdrom,if=none,readonly,format=raw,cache=writethrough,file=$ISO \
> -device ide-cd,drive=cdrom,bootindex=0 \
> -debugcon file:debug18.log \
> -global isa-debugcon.iobase=0x402 \
> -monitor stdio

Wall clock time from QEMU invocation to first install screen: 9 seconds.

Now, this script does not assign a GPU with vfio-pci, but I understand Dann
didn't do that either, yet he managed to reproduce the issue. Can someone
please paste a *minimal* QEMU command line reproducer , preferably without
vfio-pci; even more preferably with just an IDE CD-ROM? (To my
understanding, this is exactly how Dann reproduced the issue; see
comment#17.)

Also, from the comments thus far, it looks like edk2 commit 6fb8ddd36bde
makes a difference under QEMU 2.10. However, it is not clear to me if the
same edk2 commit makes a similar difference under QEMU 2.8. The original
report mentions a full system upgrade, which (I assume) upgraded both OVMF
and QEMU. Can someone -- who otherwise reproduces the issue -- please test
OVMF, built from upstream edk2, under QEMU 2.8?

Thanks.