On 02/14/20 19:12, Philippe Mathieu-Daudé wrote:
> On 2/14/20 5:37 PM, Jerry Geis wrote:
>> I dont know how to get all files listing on windows. But, I cd
>> \program files\qemu
>> dir *.fd
>> edk2-x86_64-code.fd
>> edk2-x86_64-secure-code.fd
>>
>> It seems like from other posts these might be the files - but still
>> not sure how to do "boot" a command line for UEFI.
>
> I tested/added these files in commit e54ecc70c34:
>
> NSIS: Add missing firmware blobs
>
> Various firmwares has been added in the pc-bios/ directory:
>
> - CCW (since commit 0c1fecdd523)
> - skiboot (since commit bcad45de6a0)
> - EDK2 (since commit f7fa38b74c3)
>
> Stefan can you describe how you generate the binaries in
> https://qemu.weilnetz.de/w64/ ? Maybe the bunzip2 step is not called?
>
Thank you, Phil! The following line from your patch:
+ File "${BINDIR}\*.fd"
should hopefully cover everything that Jerry needs. So I guess the only
missing piece is the right QEMU command line.
Jerry:
(1) You will have to manage the virtual machine's private variable store
file manually.
You have to create the varstore manually first, from the varstore
template: copy "edk2-i386-vars.fd" to a new file; for example, to
"my-guest.vars.fd".
Then you have to treat "my-guest.vars.fd" like another data disk, for
the guest.
Never use the "edk2-i386-vars.fd" template file itself on any QEMU
command line.
(2) Next step, choose one of the following firmware binaries:
(2a) edk2-x86_64-code.fd
(2b) edk2-x86_64-secure-code.fd
The (2a) firmware binary runs on both the i440fx ("pc") machine type,
and the q35 machine type. It does not include the Secure Boot UEFI
feature. It also does not include the edk2 SMM stack. Use this binary if
you don't care about Secure Boot for your guest, or insist on using
"pc".
The (2b) firmware binary runs only on "q35". It's strongly recommended
to use the latest version of the "q35" machine type available in your
QEMU executable, with this firmware binary. This firmware binary
includes both the Secure Boot feature, and the edk2 SMM stack. (The
latter is used to protect the former, but that's not really important
now.) The "q35" machine type restriction actually comes from the SMM
stack. Use this firmware binary if you want the Secure Boot feature.
In case you pick (2b), note that the Secure Boot *operational mode* is
not automatically enabled in your guest. You will have to enroll SB keys
/ certificates manually. You can do that e.g. in the firmware setup TUI
in the guest. You can find resources about this on the net.
(3) Assuming you've picked your firmware binary, here are the
*additional* command line options for qemu-system-x86_64 (that is, these
options should be appended after your usual options):
- For (2a):
-machine pflash0=firmware-executable,pflash1=variable-store \
-blockdev
node-name=firmware-executable,read-only=on,driver=file,filename=edk2-x86_64-code.fd
\
-blockdev
node-name=variable-store,read-only=off,driver=file,filename=my-guest.vars.fd \
- For (2b): everything you see under (2a), *plus*
-machine type=q35,smm=on \
-global driver=cfi.pflash01,property=secure,value=on \
(Don't forget to change the filename in the "firmware-executable"
blockdev, from "edk2-x86_64-code.fd" to "edk2-x86_64-secure-code.fd"!)
(4) If you'd like a progress bar (a bit of time) at the OVMF splash
screen, you can append (in either case):
-boot menu=on,splash-time=5000 \
(5) In order to capture the firmware debug log, append:
-global isa-debugcon.iobase=0x402 \
-debugcon file:ovmf_log.txt \
(6) Note that firmware-specific options that you may be used to with
SeaBIOS are not guaranteed to behave identically (or at all) with OVMF.
Some examples (not an exhaustive list):
- with the "-boot" option, only "menu" and "splash-time" are supported,
and they don't work identically to SeaBIOS
- "-boot strict=on" is always assumed
- to highlight boot order setting, "-boot order=..." does not (cannot)
work with UEFI; you have to use the device-specific "bootindex"
properties. For example, to place a virtio-scsi CD-ROM first in the
boot order, use:
-device virtio-scsi-pci,id=scsi0 \
-device scsi-cd,bus=scsi0.0,drive=BlockDevName,bootindex=0 \
^^^^^^^^^^^
If you specify at least one "bootindex" property, then you should
specify bootindex properties with *all* devices that you want to
attempt booting from. (See "strict" above.)
- Avoid switches like "-hda"; use the full-blown blockdev (backend) +
device (frontend) syntax.
(Note that libvirt would automate away almost all of the above for you.
But I'm unsure if you can, or are willing to, use libvirt on a Windows
host.)
(7) In the general case, you can't boot a 64-bit OS on a 32-bit UEFI
firmware, nor vice versa. The "bitnesses" must match. (People forget
this frequently.)
Hope this helps,
Laszlo
