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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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

Yeah, that would be a bit annoying for downstream. Maybe we could keep
in the current OVMF implementation for a little while longer and create
the new one which would be Xen specific, but which would introduce PVH
support. That would mean duplicated code upstream.

I don't think it would be possible to add PVH to the current OVMF.

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

So, normally on QEMU/KVM, in order to use this VarStore, libvirt (or
user) would add two flash device to qemu, one which gives access to this
VarStore that a guest can write to it (and so would be baked by a file
in the host), and the second flash device would be the rest of OVMF, all
its code.

In Xen, we only ever load the sum of both, and I think hvmloader might
not work if the OVMF blob is smaller than expected (meaning the
toolstack load ovmf without the VarStore so it can attach to QEMU
instead).

I think that VarStore is just a placeholder anyway, in the current
binary.

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

RAM.

If I set the ELF header properly so that it is written that the blob
must be loaded in the guest RAM just below 4G, libxc will not be able to
do anything because there is no RAM, that space is suppose to be a mem
hole, or something like that, I forgot the exact detail :(. I think also
that libxl would try to load other data like the startinfo page past the
kernel (OVMF here) and that would mean past 4G.

(In my notes from when I tried, I've written "libxc will not move ram
like hvmloader would; [and with >4G for the guest] libxc can not map
anything past 0xfee00000, and I want 0xffe00000", whatever that mean,
can find out where I found that 0xfee00000 address.)

Anyway, it didn't make sense to be to move the RAM around for some
code/data that is only use very early and never used again. And it seams
easier to have initial blob somewhere else rather trying to teach libxc
about this weirdness.

Thanks,

-- 
Anthony PERARD

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