[Xen-devel] [RFC] OVMF on PVH

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

Hi,

I've been working on booting OVMF in a PVH guest. There are few changes
that I'd like your comments on. Those are changes that I've already made
in my private branch, there are either required or will make things
easier.

## Goal

Have a single blob that can be use for both HVM and PVH guests. And be
able to start UEFI compatible guests in PVH.


## New binary, separated from QEMU/KVM one.

Right now, the rules to build the firmware are located in
`OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new platform, without
KVM support, and would like to retire the Xen support from the current
platform.  For now, I have created OvmfPkg/XenOvmf.dsc. (The change to a
new platform had been proposed by upstream.)

That would simplify Xen support in OVMF, and allow to diverge more from
OVMF where needed. That would mostly be useful during the initial boot
phase where there lots of `if xen do that, else do that`.

We can also choose some drivers that can work on both PVH and HVM, for
example, use a LAPIC timer instead of ACPI Timer.

All this mean that building OVMF for Xen would need to be change.


## ELF header

Adding an ELF header to OVMF so the blob can be loaded by libxl/libxc
without modifying those libs.

That replace a section of the OVMF binary called VarStore by that ELF
header.  It's empty and libxl doesn't know how to use it. (QEMU/KVM would
have a flash device loading the store, so it can be written to.)

With the ELF header, I can test OVMF by simply adding this in the config
file:

    type='pvh'
    kernel='/path/to/OVMF.fd'

We could use a modified `hvmloader` to load OVMF on PVH or teach libxc to
load it at a hardcoded location, but I don't see it as necessary, and if
we have one less firmware to load, it's probably better.

With the use of an ELF header comes another issue, which as to do with
were the binary needs to be loaded initially.

## Loading binary at 0x10000 (1MB, like hvmloader on HVM)

Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
hvmloader moving some RAM around to allow that.  But with the use of an
ELF header, and let libxc load the blob, it was not possible to load the
blob just below 4GB. (Or at least without modification of the toolstack I
guess.) So I've attempted to have OVMF been started from a different place
in memory. Then I had to hack a bit more in order to be able to start OVMF
from two different location (the current one for HVM guest, and a new one
that can be used for PVH). That works fine, I'll just have to find out
what upstream think about that.

## Current WIP

You can find my current branch on xenbits, it still needs to be cleanup
but it works and can boot a PVH guest:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git
branch: wip.platform-xen-pvh

To build: OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc -n $number_of_cpu

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel