[edk2] Running UEFI applications under OVMF

[JCA]

I have just started looking into UEFI in general, and EDK II and OVMF
in particular, so I may be asking trivial, even annoying, questions.
Please bear with me and my current level of ignorance.

I have been able to install EDK II in my Linux box, and I have used it
to build an instance of the OVMF which I can successfully launch under
QEMU. I also have some UEFI applications, built with the EDK II
environment, which I would like to run under OVMF. I am sure that how
to do so must be documented somewhere, but I have so far been unable
to find anything directly relevant. Can anybody in this forum provide
any pointers to documentation on how to run UEFI applications, as
created under the EDK II environment, under OVMF?

[S. Vieira]

Hi JCA

First, in your box virtuaal ( virtualbox i.e ) the UEFI simulation BIO is
enabled?! ( see it )

Second, after of the run the *.efi showed any error?

'cause after of to compile, if not showed error , so can be the your
Second, after of the run the *.efi shown any error? Config


Thanks

[S. Vieira]

===Resending miss word====

Hi JCA

First, in your box virtuaal ( virtualbox i.e ) the UEFI simulation BIO is
enabled?! ( see it )

Second, after of the run the *.efi showed any error?

'cause after of to compile, if not showed error , so can be the your config


Thanks

[JCA]

Post by S. Vieira
===Resending miss word====
Hi JCA
First, in your box virtuaal ( virtualbox i.e ) the UEFI simulation BIO is
enabled?! ( see it )
Second, after of the run the *.efi showed any error?
'cause after of to compile, if not showed error , so can be the your config

Thanks for your reply. First, I am running OVMF under qemu.Second,
OVMF seems to be running under qemu all right. That is, I am getting
the UEFI shell and different configuration screens. Finally, I have a
simple UEFI application that I created with EDK II. That is, I have a
file called S1.efi that I generated, without any compilation warnings
or errors, under EDK II. What I am trying to find out is how to run
S1.efi under OVMF.

[Laszlo Ersek]

Post by JCA
I have just started looking into UEFI in general, and EDK II and OVMF
in particular, so I may be asking trivial, even annoying, questions.
Please bear with me and my current level of ignorance.
I have been able to install EDK II in my Linux box, and I have used it
to build an instance of the OVMF which I can successfully launch under
QEMU. I also have some UEFI applications, built with the EDK II
environment, which I would like to run under OVMF. I am sure that how
to do so must be documented somewhere, but I have so far been unable
to find anything directly relevant. Can anybody in this forum provide
any pointers to documentation on how to run UEFI applications, as
created under the EDK II environment, under OVMF?

I'd try one of the following two:

(1) create a virtual disk image with "qemu-img", and use the "guestfish"
utility to format it as FAT32 and to copy your UEFI application binary
to it. Then launch qemu with this image attached to it as an IDE drive
or a virtio-blk drive or a virtio-scsi scsi-hd.

Instead of "guestfish", you can populate the image with "mtools" as
well. See the "-i" option in the mtools manual.

(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
options:

-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0

In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Laszlo

[JCA]

Post by Laszlo Ersek

Post by JCA
I have just started looking into UEFI in general, and EDK II and OVMF
in particular, so I may be asking trivial, even annoying, questions.
Please bear with me and my current level of ignorance.
I have been able to install EDK II in my Linux box, and I have used it
to build an instance of the OVMF which I can successfully launch under
QEMU. I also have some UEFI applications, built with the EDK II
environment, which I would like to run under OVMF. I am sure that how
to do so must be documented somewhere, but I have so far been unable
to find anything directly relevant. Can anybody in this forum provide
any pointers to documentation on how to run UEFI applications, as
created under the EDK II environment, under OVMF?

(1) create a virtual disk image with "qemu-img", and use the "guestfish"
utility to format it as FAT32 and to copy your UEFI application binary
to it. Then launch qemu with this image attached to it as an IDE drive
or a virtio-blk drive or a virtio-scsi scsi-hd.
Instead of "guestfish", you can populate the image with "mtools" as
well. See the "-i" option in the mtools manual.
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
that you mentioned to my invocation of qemu:

qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

Actually, this is the command line that I am using:

qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0

Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.

I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

[Laszlo Ersek]

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

Thanks
Laszlo

[JCA]

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

Thanks for your help again. Embarrassingly though, still no cigar here:

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'

This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

[Laszlo Ersek]

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

Thanks
Laszlo

[JCA]

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

It is QEMU 2.2.0 under Slackware 14.1. A Google search on the error
returned has yet to yield anything really useful.

[JCA]

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

It is QEMU 2.2.0 under Slackware 14.1. A Google search on the error
returned has yet to yield anything really useful.

Well, I got it to work, but I do not know how
orthodox/proper/efficient my solution is. Here it is, in case it can
be use of others, and also in case anyone can propose something
better.

Since I am running QEMU under Linux, I went ahead and created a FAT32
partition on some external device (actually, a USB stick.) After that
partition got mounted in my Linux system at mount point /media/HD, I
created a symbolic link as follows:

ln -s /media/HD .

in the directory from which I am invoking QEMU. From that directory I did

qemu-system-i386 -pflash ./bios.bin -drive file=fat:./HD

This starts my OVMF instance successfully, and after a minute or two I
get the UEFI command line prompt. At this prompt I type

fs0:

and this gives me access to the FAT32 partition above. In this
partition I have a file named S1.efi, which I created using the EDK II
infrastructure. From the UEFI command line I simply do

S1

and the (very simple) UEFI application S1 gets executed all right.

One hurdle overcome :-)

[Laszlo Ersek]

Post by JCA

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
(2) A variant of the above. Create an empty directory on the host, and
copy your UEFI application binary there. Then use the following qemu
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
In either case, after entering the UEFI shell, you should be able to
navigate to the binary and run it.

Second option, here is what I am getting after appending the options
qemu-system-i386: -device virtio-blk-device,drive=drive0: No
'virtio-bus' bus found for device 'virtio-blk-device'

That's because "virtio-blk-device" means the MMIO (memory mapped) virtio
transport variant, and instead of that, on the i386 target, you need the
PCI variant. Use "virtio-blk-pci" please.

Post by JCA
qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-device,drive=drive0
Removing all the options after hda-contents my OVMF starts correctly,
and I can get to the UEFI shell without issues.
I have not been able to try the first option yet, for I don't have the
guestfish utility. I'll try and get it.

Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

It is QEMU 2.2.0 under Slackware 14.1. A Google search on the error
returned has yet to yield anything really useful.

Well, I got it to work, but I do not know how
orthodox/proper/efficient my solution is. Here it is, in case it can
be use of others, and also in case anyone can propose something
better.
Since I am running QEMU under Linux, I went ahead and created a FAT32
partition on some external device (actually, a USB stick.) After that
partition got mounted in my Linux system at mount point /media/HD, I
ln -s /media/HD .
in the directory from which I am invoking QEMU. From that directory I did
qemu-system-i386 -pflash ./bios.bin -drive file=fat:./HD
This starts my OVMF instance successfully, and after a minute or two I
get the UEFI command line prompt. At this prompt I type
and this gives me access to the FAT32 partition above. In this
partition I have a file named S1.efi, which I created using the EDK II
infrastructure. From the UEFI command line I simply do
S1
and the (very simple) UEFI application S1 gets executed all right.
One hurdle overcome :-)

Any directory on any host side filesystem should do, as long as its
entire contents satisfy the restrictions placed by a FAT16 filesystem.
(-drive file=fat:XXX emulates a FAT16 filesystem, as far as I remember.)
This includes file name, file size, volume size restrictions; possibly
others.

Thanks
Laszlo

[Laszlo Ersek]

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

It is QEMU 2.2.0 under Slackware 14.1. A Google search on the error
returned has yet to yield anything really useful.

Okay, with some experimentation I figured out the error on your end. I
can get the same error message with:

qemu-system-i386 -device virtio-blk-pci,drive

The issue is that you must have passed the "drive" property without
assigning any backend identifier to it, such as in

qemu-system-i386 -device virtio-blk-pci,drive=drive0

In this case, "drive" is interpreted as a boolean flag (hence "on"), and
it doesn't make sense.

In general, qemu has backends (host-side stuff) and frontends (devices
that the guest sees).

You set up backends with -drive and -netdev (and others), and each of
these backend options takes an id=XXXX parameter.

Then, you can configure frontends (devices that the guest sees) with
-device virtio-blk-pci, -device virtio-net-pci, and so on.

And in these frontend options, you have to pass some property (the
property name depends on the exact device type) that identifies what
backend the frontent should be connected to. For example, the "drive"
property for "-device virtio-blk-pci" must resolve to the "id" property
of a -drive backend. Similarly, the "netdev" property for "-device
virtio-net-pci" must resolve to an earlier -netdev's "id" property.

Examples:

-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \
-device virtio-net-pci,netdev=netdev0,bootindex=2 \

Search this example for the string "netdev0". The first option is the
backend (host side config), and the second option is the frontend (the
device that the guest sees).

Similarly from earlier in this thread,

-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0

here the connecting identifier between backend and frontend is "drive0".
(It's an arbitrary choice.)

So, again I think the error in your case was that you left off "=drive0".

Laszlo

[JCA]

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek

Post by JCA

Post by Laszlo Ersek
Option 2 should suffice for quick & dirty testing, if you can get
virtio-blk-pci working.

qemu-system-i386: -device virtio-blk-pci,drive: Property
'virtio-blk-device.drive' can't find value 'on'
This keeping exactly the same command line as above, but replacing
virtio-blk-device with virtio-blk-pci.

What qemu are you using? My guess is "ancient". That command line works
for me.

It is QEMU 2.2.0 under Slackware 14.1. A Google search on the error
returned has yet to yield anything really useful.

Okay, with some experimentation I figured out the error on your end. I
qemu-system-i386 -device virtio-blk-pci,drive
The issue is that you must have passed the "drive" property without
assigning any backend identifier to it, such as in
qemu-system-i386 -device virtio-blk-pci,drive=drive0
In this case, "drive" is interpreted as a boolean flag (hence "on"), and
it doesn't make sense.
In general, qemu has backends (host-side stuff) and frontends (devices
that the guest sees).
You set up backends with -drive and -netdev (and others), and each of
these backend options takes an id=XXXX parameter.
Then, you can configure frontends (devices that the guest sees) with
-device virtio-blk-pci, -device virtio-net-pci, and so on.
And in these frontend options, you have to pass some property (the
property name depends on the exact device type) that identifies what
backend the frontent should be connected to. For example, the "drive"
property for "-device virtio-blk-pci" must resolve to the "id" property
of a -drive backend. Similarly, the "netdev" property for "-device
virtio-net-pci" must resolve to an earlier -netdev's "id" property.
-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \
-device virtio-net-pci,netdev=netdev0,bootindex=2 \
Search this example for the string "netdev0". The first option is the
backend (host side config), and the second option is the frontend (the
device that the guest sees).
Similarly from earlier in this thread,
-drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
-device virtio-blk-device,drive=drive0
here the connecting identifier between backend and frontend is "drive0".
(It's an arbitrary choice.)
So, again I think the error in your case was that you left off "=drive0".

You are right. The command I originally executed was

qemu-system-i386 -pflash ./bios.bin -drive
file=fat:./hda-contents,id=drive0,if=none,format=raw -device
virtio-blk-pci,drive

Appending '=drive0' to it did the trick. Thanks.