OVMF for Xen PVH

OVMF for Xen PVH

[Anthony PERARD]

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,

-- 
Anthony PERARD

Re: OVMF for Xen PVH

[Laszlo Ersek]

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

Re: OVMF for Xen PVH

[Anthony PERARD]

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