[RFC] fix for virt-install failure with OVMF?

Aaron Young

Hello, we have found what we think is a BUG in OVMF, but wanted to run it by the rfc list first to confirm.

We have discovered that the following virt-install command causes the latest OVMF code to fail to boot into the installer ISO.

virt-install --boot uefi --name Guest1 --ram 4096 --vcpus 1 --disk
path=/Disks/Guest1_disk.img --location /ISO/OracleLinux-R7-U4-Server-x86_64-dvd.iso --network bridge=virbr0,model=virtio --os-type linux --noreboot --boot=hd,cdrom,loader=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,loader_ro=yes,loader_type=pflash,loader_secure=no,nvram=/Images/OVMF_VARS.pure-efi.Guest1.fd --video vga --graphics vnc,port=5999

Instead of booting to the installer ISO, we drop into the kernel shell like so:

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick
or /boot
after mounting them and attach it to a bug report.

:/# ls /sys/block


This change to the code allows this virt-install command (above) to succeed:

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 45d0ee9..997acaf 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1514,14 +1514,14 @@ PlatformBootManagerAfterConsole (
Tcg2PhysicalPresenceLibProcessRequest (NULL);

- // Process QEMU's -kernel command line option
+ // Perform some platform specific connect sequence
- TryRunningQemuKernel ();
+ PlatformBdsConnectSequence ();

- // Perform some platform specific connect sequence
+ // Process QEMU's -kernel command line option
- PlatformBdsConnectSequence ();
+ TryRunningQemuKernel ();

EfiBootManagerRefreshAllBootOption ();

i.e. if we move the TryRunningQemuKernel() call to after PlatformBdsConnectSequence(), it works... i.e. the virt-install commands boots to the installer ISO and all is good.

What it appears to be happening is the CD/IDE device for the ISO is not being connected with the existing code. The code change allows the CD to be connected before we call TryRunningQemuKernel(). With the code change we see this in the debug log, but without the code change we do not:
< Found Mass Storage device: PciRoot(0x0)/Pci(0x1,0x1)
< SataControllerStart START
< InstallProtocolInterface: A1E37052-80D9-4E65-A317-3E9A55C43EC9 BEF07EA0
< SataControllerStart END status = Success
< ==AtaAtapiPassThru Start== Controller = BEFA3C98
< [secondary] channel [master] [cdrom ] device
< CalculateBestPioMode: AdvancedPioMode = 3
< IdeInitCalculateMode: PioMode = 3
< CalculateBestUdmaMode: DeviceUDmaMode = 203F
< IdeInitCalculateMode: UdmaMode = 5

My question is: Is this a legitimate change to the boot flow to OVMF? Is there a reason that TryRunningQemuKernel() is currently called prior to PlatformBdsConnectSequence()? (Other than just an optimization to reduce unnecessary connections)? I fear that this change in the boot flow fixes this case but may break something else.

For completeness, here is the qemu command that is exec'd by the virt-install command for reference:
/usr/bin/qemu-system-x86_64 -name guest=Guest1,debug-threads=on -S -object secret,id=masterKey0,format
=raw,file=/var/lib/libvirt/qemu/domain-5-Guest1/master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=of
f,dump-guest-core=off -cpu Skylake-Client-IBRS -drive file=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,if=pf
lash,format=raw,unit=0,readonly=on -drive file=/Images/OVMF_VARS.pure-efi.G
uest1.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -u
uid 5a3a191d-8cac-4400-80bb-59136bd05580 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd
=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global
kvm-pit.lost_tick_policy=delay -no-hpet -no-reboot -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.dis
able_s4=1 -boot strict=on -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.jdC2ks -initrd /var/lib/libvi
rt/boot/virtinst-initrd.img.aHyTeQ -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-u
sb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,master
bus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pc
i.0,addr=0x4.0x2 -drive file=/Disks/Guest1_disk.img,format=raw,if=none,id=d
rive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file
de0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=28
,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:04:f4:9e,
bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=ballo
on0,bus=pci.0,addr=0x5 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=den
y -msg timestamp=on

Any comments/suggestions/etc. are welcome. I plan to send the patch to the devel list in the next day or so.

Thanks in advance,

-Aaron Young

Join rfc@edk2.groups.io to automatically receive all group messages.