QEMU Machine Type Q35 + OVMF - does not recognize CDROM drives

JonDahm · 2016-08-18 00:52:59

Context
Lately, I've been trying to get a Windows virtual machine up and running with a passed-through graphics card and hardware virtualization so I can play games without needing to reboot my computer. I've been banging my head up against a wall for the past several days just trying to get Windows installed, let alone get passthrough up and running. This is probably only the first of my problems that I'll be asking about.

I am trying to use the q35 machine type because the ArchWiki QEMU page suggested that in order to use PCI passthrough, I needed to enable the iommu machine property, which the default qemu machine type doesn't support ("warning: i440fx doesn't support emulated iommu").

I am trying to use OVMF because a cursory search of the ArchWiki implies that it's helpful, if not necessary, for PCI passthrough.

Problem
For whatever reason, when I set the emulated machine type to "q35", OVMF stops recognizing the CDROMs I'm configuring. Here is my script. I've made this script as minimal as possible. I've only left the acceleration and memory parameters because Windows requires KVM to be in use.

qemu-system-x86_64  \
	-machine type=q35,accel=kvm \
	-cpu host  \
	-enable-kvm  \
	-m 4G  \
	-drive if=pflash,format=raw,file=/home/jdahm/virtual-machines/windows-gaming-ovmf.bin  \
	-boot order=d  \
	-drive media=cdrom,file=/home/jdahm/virtual-machines/installers/win8.1-64bit.iso,format=raw

When I use this script, QEMU jumps straight to the EFI shell. When I open the boot manager, the only options I see are "EFI Internal Shell" and "EFI Network." The shell option naturally takes me to EFI shell. The EFI Network fails to boot, showing a period and an underscore before, potentially, rebooting after about a minute.

On the other hand, if I remove "type=q35" and rerun the script, opening the boot manager shows "EFI Floppy", "EFI Floppy 1", "EFI DVD/CDROM", and "EFI DVD/CDROM 1" in addition to the previous options. Selecting "EFI DVD/CDROM 1" boots the windows installer disk. The boot sequence still takes me nearly immediately to the EFI shell, but that's another problem for another day.

Finally, if I remove the -drive parameter specifying the OVMF bios (to return to QEMU's default SeaBIOS), the boot sequence jumps straight to the installer disk, no problem. This is clearly an issue with OVMF and q35.

Things I've Tried

Using the -cdrom parameter. Looks like the following:

	-cdrom /home/jdahm/virtual-machines/installers/win8.1-64bit.iso

Explicitly specifying the CDROM drive's interface as IDE and as SCSI using the "if" drive option.

Specifying an extra device of type "ide-cd" and of type "scsi-cd" to accompany the drive. Looks like the following:

	-drive id=installer-cd,if=none,file=/home/jdahm/virtual-machines/installers/win8.1-64bit.iso,format=raw  \
	-device ide-cd,drive=installer-cd

None of these changes OVMF's behavior, except specifying a scsi-cd device, which stops QEMU before it even starts with the error "No 'SCSI' bus found for device 'scsi-cd'".

Searches I've Done

Arch Linux "Applications & Desktop Environments" Forums for "ovmf". This brought me the following results:
- One topic with a similar initial symptom as me, but what turns out to be a completely different problem.
Google for "ovmf qemu q35 cannot find cdrom". This brought me the following results:
- A RedHat bug report with identical symptoms, but from 2013 with SeaBIOS. It apparently worked when using the "ide-cd" device, but not the "ide-drive" device. A developer did note that replacing the ACPI table with a file called "q35-acpi-dsdt.aml" fixed the issue in qemu 1.3, but that this should not be necessary in qemu 1.4 (and, I presume later versions of qemu as well). I haven't tried this yet.
- A Debian bug report with similary symptoms, but from 2014 with SeaBIOS. It was solved by using -drive options rather than -cdrom options and specifying a SCSI interface rather than the default IDE interface. This actually mentions the RedHat bug I noted as something that didn't work.

Other Information

My installations of qemu and ovmf come from the official Arch repositories. To go along with the 64bit guest I'm running, I'm using the 64bit OVMF image.
I performed a full system update earlier this morning.
The Windows 8.1 installation disk came straight from Microsoft's website.
My CPU is an Intel Core i5-6600K. My Motherboard is an Asus Z170-P. Both are listed as supporting Intel VT-d.

I can list any other pertinent information if you think I've left anything off.

----------------------------------------------

Can anyone see what I've done wrong? I'm really wracking my head against a wall here trying to figure out how to proceed. Do I need a more recent version of OVMF? I notice that the Arch package is flagged as out of date. Have I specified something wrong? I feel like with the number of people running Windows VMs in QEMU under KVM, somebody should have noticed this problem before - the fact that I can't find any help on it seems to imply I'm doing something wrong.

alive4ever · 2016-08-18 11:58:11

It seems that currently packaged ovmf from Arch repository doesn't detect CDROM media when machine is set to Q35.
Have you tried using git version of OVMF?

In case building OVMF from source is not desired, you may extract latest OVMF from jenkins rpm repository. You should be able to extract the rpm using bsdtar and use the extracted ovmf from the rpm and see if it works.

You may also try my edk2-ovmf aur package.

Last edited by alive4ever (2016-08-19 06:20:53)

JonDahm · 2016-08-20 07:14:33

alive4ever wrote:

It seems that currently packaged ovmf from Arch repository doesn't detect CDROM media when machine is set to Q35.

That's really unfortunate. We should fix that.

alive4ever wrote:

Have you tried using git version of OVMF?

Tonight I've been trying to compile OVMF from the latest source on GitHub. Unfortunately, the binary I'm producing doesn't even start up properly. When I download an older, pre-built version of OVMF (build r15214, same as provided by the `ovmf-bin` AUR package at the time of this writing), the binary provided starts up just fine. Substituting it with the binary I've built leaves QEMU in a perpetual state of "Guest has not initialized the display (yet)."

Here are the official guides I (generally) followed, for reference. I've found them to be out-of-date, missing information, and even misleading in places (like suggesting that you need to use 'su' to install packages - yikes!), so I've had to improvize a little.

Here are the steps I followed:

Installed `git`, `subversion`, `python2`, `iasl`, and `nasm` packages to make sure I have everything. (The official guides didn't mention anything about needing nasm - that came up when the build started failing because the build scripts couldn't find it. They did mention needing the `base-devel` group and `glibc` package, but those were already installed on my system.)

Executed the following bash commands to clone the latest repository and set up the build tools.

~$ mkdir src
~$ cd src
src$ git clone https://github.com/tianocore/edk2
src$ make -C edk2/BaseTools 1>basetools-build-log 2>&1
src$ cd edk2
## Yes, the following is written correctly. "." is a built-in command that
## takes a script and runs its commands in the current shell context, rather
## than within a subshell context. See the Bash Reference Manual:
## https://www.gnu.org/software/bash/manual/bashref.html#Bourne-Shell-Builtins
## This is important for this script, which adds to our PATH to provide easy
## access to the tools in BaseTools - particularly "build".
edk2$ . edksetup.sh BaseTools

Modified Conf/target.txt to set the following variables:

ACTIVE_PLATFORM = OvmfPkg/OvmfPkgX64.dsc
TARGET_ARCH = X64
## I have GCC 6.1, but EDK II doesn't have explicit support for it -- GCC 5 is the newest version they explicitly support
TOOL_CHAIN_TAG = GCC5

Executed the following to build OVMF and log its output.
```
edk2$ build 1>ovmf-build-log 2>&1
```

The resulting binaries are in Build/OvmfX64/DEBUG_GCC5/FV. The relevant binaries are OVMF.fd (efi code+efi variables), OVMF_CODE.fd (efi code only), and OVMF_VARS.fd (efi variables only). I'm using OVMF.fd in the same way I used the binary provided by the official repository. In fact, I've reduced the qemu invokation to the following one-liner, where "ovmf-x64.bin" is a copy of the built binary:

qemu-system-x86_64 -drive if=pflash,format=raw,file=ovmf-x64.bin

I've also tried setting TARGET in Conf/target.txt to RELEASE rather than DEBUG, and I get the same problem. The BaseTool build log can be found in this pastebin link. Unfortunately, the OVMF build logs are well over the 0.5MiB limit that Pastebin places on free uploads, so I can't share those here yet until I find another way.

I'm not sure what's wrong here. I've got a little more poking around to do before I declare defeat in this avenue, but I thought I'd give a progress update.

--------------------

alive4ever wrote:

In case building OVMF from source is not desired, you may extract latest OVMF from jenkins rpm repository. You should be able to extract the rpm using bsdtar and use the extracted ovmf from the rpm and see if it works.
You may also try my edk2-ovmf aur package.

I may try these if I can't get building from scratch to work. Thanks for the links!

Arch Linux

#1 2016-08-18 00:52:59

QEMU Machine Type Q35 + OVMF - does not recognize CDROM drives

#2 2016-08-18 11:58:11

Re: QEMU Machine Type Q35 + OVMF - does not recognize CDROM drives

#3 2016-08-20 07:14:33

Re: QEMU Machine Type Q35 + OVMF - does not recognize CDROM drives

Board footer