debug: 0.189
other: 0.160
semantic: 0.151
device: 0.108
graphic: 0.075
network: 0.051
performance: 0.051
vnc: 0.040
PID: 0.035
socket: 0.033
files: 0.032
permissions: 0.031
boot: 0.026
KVM: 0.016
debug: 0.604
other: 0.070
boot: 0.044
semantic: 0.043
files: 0.038
device: 0.033
performance: 0.031
network: 0.029
PID: 0.027
graphic: 0.022
socket: 0.022
KVM: 0.013
permissions: 0.012
vnc: 0.011

Running an edk2 based bios

This is not necessarily a bug, however I wasn't sure were to get help.

I am currently working on using QEMU  to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command:

qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none

However, when running the same command using  our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features. 

If anyone has any insight on what the issue might be I would greatly appreciate any help.

"Guest has not initialized display" simply means that the guest code you're running has not done anything to the display device (VGA in this case). There are two main reasons for this:

 (1) the guest code isn't intended to output to the display -- perhaps it sends its output to the serial port instead. In this case the fix is to use the right QEMU arguments to send the serial port output somewhere you can read it (or to reconfigure the guest code to output where you want it to).

 (2) the guest code is intended to output to the display, but it crashed before it got as far as doing that. In this case, the fix is to debug your guest code. QEMU's gdbstub is usually a good tool to use here. If you control the guest code (ie you can modify and recompile it) you can also add extra debugging to it (like making it output more information earlier, or output debugging trace information to the serial port so you can see how far it has got).

My guess would be that this is a variation on 2 caused by your BIOS being compiled to assume different hardware from what QEMU is providing -- if the BIOS tries to write to a device that isn't present it will likely crash or go into an infinite loop.