Re: [Xen-devel] [RFC] OVMF on PVH

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> 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.

Changing things in xen.git is easy and fine. This is more about
introducing a burden for downstream packagers because they need to build
a separate packages.

This is not saying I'm against this idea in any way, just something that
comes to my mind.

> 
> 
> ## 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.)

But long term we might want to support VarStore (that is used to stored
config, right?). How are we going to do that in the future if we
repurpose it now?

> 
> 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.

If you specify the virt_addr (?) in the ELF header, libxc should know
how to deal with that? What is missing in the current toolstack code?

Wei.

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