Re: [edk2] Xen OVMF early discussions

Subject: Re: [edk2] Xen OVMF early discussions

From: Bei Guan <>

To: Jordan Justen <>

Date: 2011-04-14 08:48:02

Hi All,

There is a patchset in Xen-devel mailing list to support the SeaBIOS.

The size of SeaBIOS is 128kb. According to the patch, the SeaBIOS is loaded at 0x000E0000 (SEABIOS_PHYSICAL_ADDRESS).

So, maybe we can build a binary OVMF loader using EDK II, and it will be loaded by Xen hvm builder. The OVMF loader will load OVMF, VGA BIOS and do other stuff as Xen hvm loader does (if necessary).

The Xen hvm loader can't load a bios larger than 1MB currently. So, if we use the Xen hvm loader to load OVMF, we must modify the hvm loader and maybe also the hvm builder. But, I don't know whether OVMF can work well or not if loaded by modified Xen hvm loader.

Bei Guan

2011/4/13 Bei Guan <>
Hi all,

A brief summary of the discussions above can be made as the following. I hope I could understand all of them except for some questions.

Up to now, I think two main methods have been made.

The First One: Enable OVMF to boot on Xen by replacing the HVM loader with a domain loader builded in EDK II or with a modified OVMF (OVMF has a domain builder/loader currently? Is it the "SEC"?).

Since HVM loader is 32 bit ELF and can be loaded at 1MB, and it performs all the work including set up ACPI tables, MP table, SMBIOS table and E820 table as well as copying BIOS down to 0xF0000 and VGA BIOS, then transfer to real 16 bit mode and jump to BIOS code at 0xFFFFF0. We can implement a new domain loader in the EDK II based on the Xen domain builder, and then it can be loaded by Xen. The new domain loader does some similar things (if necessary) like the HVM loader and then loads OVMF to proper location, such as below 4GB, and also loads cirrus VGA BIOS, and then jumps to OVMF in 16 bit mode. (This new domain loader can be implemented by referencing to Xen HVM loader.)

Alternatively, we could modify OVMF (mainly modify its domain builder/loader?) to make it loaded by Xen domain builder directly. If it is loaded at a fixed address, we don't need to change the Xen code. Otherwise, we maybe need to change the Xen hvm domain builder to map the modified OVMF to a location other than 1MB.


Maybe we don't need to change the Xen code. But, more work need to be done in OVMF.

The Seconded One: Enable OVMF to boot on Xen using the Xen HVM loader.

Because of OVMF is about 1MB, which is larger than Xen RomBIOS. We need to make HVM loader loading OVMF and mapping it below 4GB (I think we need to implement it in HVM loader). And then, OVMF start in 16-bit mode and then jump to the below 4GB.

The details may be: 1) Load the cirrus VGA BIOS; 2) Copy FD to 4MB (or other address?) 3) Locate and transfer to PEI code.

Does this mean we need to separate the SEC code from the OVMF?


Need to change the Xen HVM loader.

Other Possible Methods:

Check if we can get Xen to adopt the same ROM/PFLASH model like QEMU for loading firmware below 4GB. If yes, it will be much easy.


Bei Guan

2011/4/11 Bei Guan <>

2011/4/11 Bei Guan <>

2011/4/11 Jordan Justen <>
On Sat, Apr 9, 2011 at 18:22, Andrei Warkentin <> wrote:
> On Sat, Apr 9, 2011 at 6:04 PM, Jordan Justen <> wrote:
>> If we can't easily load a 2nd image for OVMF, then we could just tack
>> the OVMF image onto the loader code, and still do something similar.
> Yes, the FD would have to be embedded in the loader just like current
> BIOS/VGABIOS are embedded.
> Keep mind that if you want to base the FD somewhere below 4GB, then
> you have to modify Xen domain builder to map it there from the real
> location it is in. Otherwise we can just modify the FDF to be based at
> some fixed address like 4MB, and copy it there from within our
> modified hvmloader.
> The hvmloader also has a facility to load a second image (in use for
> kernel+initrd), but it's not as useful as it sounds, since base
> address where FD is loaded cannot be arbitrary if you are going to
> include XIP code (PEIMs,PEI...SEC) in the FV.
> Another issue is if the current OVMF SEC code is robust enough to be
> invoked in some other location than 0xfffffff0. I.e. since the whole
> FD will be linked to say, 4MB, will the SEC work right if we copy the
> top 64kb to 0xf0000 and jump in real mode to ffff:fff0? This is why I
> wanted to avoid the OVMF SEC at all.

Yes, I think we can update OVMF's reset-vector code to operate at
another well-known address. I might suggest the top living at 64MB.

But, I also think we might want to consider taking both paths for
supporting OVMF on Xen.
1. Enable OVMF to be able to boot without Xen changes as you describe
2. See if we can get Xen to adopt the same model as QEMU for loading
firmware just below 4GB.

The reason for item 2 is that I'm working to enable better
non-volatile variable support in QEMU, by leveraging the -pflash
support in QEMU. This would be exposed in the VM as a CFI device
(very firmware hub like), and memory mapped just below 4GB. So, if we
can get Xen to adopt the same ROM/PFLASH model like this, then we can
use the same method for supporting NV Vars.

> 0) Invoke VGA BIOS (just farcall to it in RM16) so we get vga text
> working (this needs dummy IVT that just irets for everything)

Does Xen support cirrus VGA like QEMU, or could we develop a native
UEFI rom to support the video device?

There are acirrusVGA BIOS and a standard VGA BIOS in hvmloader. And the standard VGA BIOS is always loaded according to the PCI devices(xen/tools/firmware/hvmloader/hvmloader.c pci_setup()). However, since Xen doesn't change the interfaces of the emulated graphics cards from QEMU, I think we can use the OVMF graphic BIOS. I will try it.

The following are part of the debugging message of Cirrus VGABIOS and OVMF Cirrus VGABIOS loaded by hvmloader respectively. As Tim said, the Cirrus VGABIOS is loaded successfully if we add an option "stdvga=0" in HVM config file. I just replaced the Cirrus VGABIOS with OVMF Cirrus VGABIOS in the /tools/firmware/hvmloader/hvmloader.c. So, the OVMF VGABIOS is loaded in the same place as the Cirrus VGABIOS. But, It doesn't work correctly. Maybe it need the OVMF on Xen environment.

[debugging message of Cirrus VGABIOS loaded by hvmloader]
(XEN) HVM9: Loading Cirrus VGABIOS ...
(XEN) HVM9: Loading PCI Option ROM ...
(XEN) HVM9: - Manufacturer:
(XEN) HVM9: - Product name: gPXE
(XEN) HVM9: vm86 TSS at fc002800
(XEN) HVM9: BIOS map:
(XEN) HVM9: c0000-c8fff: VGA BIOS
(XEN) HVM9: c9000-d6fff: Etherboot ROM
(XEN) HVM9: eb000-eb158: SMBIOS tables
(XEN) HVM9: f0000-fffff: Main BIOS
(XEN) HVM9: E820 table:
(XEN) HVM9: [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM9: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM9: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM9: HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM9: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM9: [04]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM9: HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM9: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM9: Invoking ROMBIOS ...
(XEN) HVM9: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d9 entering stdvga and caching modes
(XEN) HVM9: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM9: Bochs BIOS - build: 06/23/99
(XEN) HVM9: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM9: Options: apmbios pcibios eltorito PMM
(XEN) HVM9: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM9: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10000 MBytes)
(XEN) HVM9: IDE time out
(XEN) HVM9: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM9: IDE time out
(XEN) HVM9: Press F12 for boot menu.
(XEN) HVM9: Booting from CD-Rom...
(XEN) HVM9: 699MB medium detected
(XEN) HVM9: Booting from 0000:7c00

[debugging message of OVMF Cirrus VGABIOS loaded by hvmloader]
(XEN) HVM10: Loading OVMF Cirrus VGABIOS ...
(XEN) HVM10: Loading PCI Option ROM ...
(XEN) HVM10: - Manufacturer:
(XEN) HVM10: - Product name: gPXE
(XEN) HVM10: vm86 TSS at fc002800
(XEN) HVM10: BIOS map:
(XEN) HVM10: c0000-c4fff: VGA BIOS
(XEN) HVM10: c8000-d5fff: Etherboot ROM
(XEN) HVM10: eb000-eb158: SMBIOS tables
(XEN) HVM10: f0000-fffff: Main BIOS
(XEN) HVM10: E820 table:
(XEN) HVM10: [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM10: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM10: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM10: HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM10: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM10: [04]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM10: HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM10: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM10: Invoking ROMBIOS ...
(XEN) HVM10: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $

Bei Guan

Bei Guan

> 1) Copy the embedded FD to 4MB since that is the base address in FDF.
> 2) Locate and transfer control to PEI Core.

I recommend we go with 64MB-sizeof(OVMF), and then jump to 64MB-0x10
in 16-bit mode. Modifying UefiCpuPkg/ResetVector/Vtf0 to support this
(as a short term solution) would not be too difficult.

Then most of the current OVMF boot flow could be retained.