Re: OVMF for Xen PVH

[Anthony PERARD <anthony.perard@citrix.com>]

On Thu, Sep 08, 2016 at 12:24:46PM +0200, Laszlo Ersek wrote:
> 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.

Right now, I can already use the same OVMF binary for both KVM and Xen
HVM on x86.

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

Yes, that might be an issue. We are going to need an extra module for
PV network if we want to boot from network in an environment where
there is no QEMU, so no emulated NIC.

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

Well, we do have our CI loop (osstest) running upstream OVMF with Xen,
but it still needs someone to look at the result. I usually try to keep
an eye on them.

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

I'll wait.

Thanks,

-- 
Anthony PERARD