Re: OVMF for Xen PVH

[Laszlo Ersek <lersek@redhat.com>]

On 09/08/16 11:38, Anthony PERARD wrote:
> Hello,
> 
> We are introducing a new virtualisation mode in Xen called PVHv2 (also
> called hvmlite in the past). We would like to have a UEFI firmware
> running on it to make it easier to start a guest. (Right now, I think it
> involves supplying the guest kernel to the guest config, like a PV
> guest.)
> 
> I'm exploring different possibility of what could be done, and what
> should be avoided. It would be nice to have only one binary for both
> PVHv2 guest and HVM guest.
> 
> Would it be possible to introduce a different entry point in OVMF? The
> current one cannot be used at the start of the day of a PVHv2 guest.
> 
> If not, we'll try to use the current entry point or create a new package
> like it has been done for Xen on ARM.
> 
> Thanks for any feedback,
> 

I've been thinking about having a shared OVMF binary for Xen and
QEMU/KVM (from a different perspective), and I did recall that ArmVirt
has separate platform DSCs / FDFs for Xen and QEMU.

The question that made me think about this is the number and size of
modules that we now build into the OVMF binary. The binary has been
continuously growing (internally), and while Ard did some fantastic work
on enabling -Os for a bunch of edk2 compilers and platforms, the
compressed size (= the ultimate utilization of the flash chip) has not
gone down significantly, if I recall correctly.

Growing the non-compressed DXEFV (which -Os mitigates significantly) is
not terribly hard, as long as we don't outgrow OVMF_CODE.fd (1920 KB),
i.e., the external thingy after compression. Outgrowing OVMF_CODE.fd
might be major pain for distros however, so I've been thinking about
trimming the builds statically.

There's some low hanging fruit for that; for example the virtio drivers
should only go into the qemu/KVM build, same for the SMM driver stack,
same for the pflash driver. Whereas the XenPV drivers, the FS-based
varstore emulation, etc should go only into the Xen build.

So, from this (independent) POV, I'd prefer separate builds for Xen and
qemu/KVM.

Regarding the entry point itself, the SMM work has complicated those
early (= SEC / PEI) modules quite a bit (for example, grep OvmfPkg for
"PcdSmmSmramRequire"). I think if you start with a separate platform,
that will make your work easier (giving you more freedom in
accommodating both PVHv2 and HVM, without regard to qemu/KVM), and allow
me to keep my sanity -- think regressions, reviews, etc :)

Here's another point I've been thinking about, on-and-off: I find it
regrettable that we don't have any official co-maintainer in
Maintainers.txt for OvmfPkg's Xen parts. We've regressed Xen a few times
in the past because none of the OvmfPkg co-maintainers run Xen. This
should certainly be fixed.

Now, if you create a new platform (DSC + FDF) for Xen, that sort of
forces someone from the Xen community to assume co-maintainership for
the Xen bits. (Hopefully those bits would be easily identifiable by
pathname.) I'd welcome that *very much*.

So, I prefer a separate platform. I'd suggest to extract the Xen
platform with the current functionality first (with all those additional
benefits), then rework the new Xen platform to accommodate PVHv2 as well
(possibly with different Sec / PlatformPei modules etc).

Do wait for feedback from Jordan please.

Thanks
Laszlo