Re: [edk2-devel] deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in OvmfPkg

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 24 May 2021 at 10:42, Laszlo Ersek <lersek@redhat.com> wrote:
>
> Hi,
>
> the "OvmfXen.dsc" platform supports not only HVM guests, but also PVH
> guests. This platform does not run on QEMU.
>
> The historical "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc", "OvmfPkgX64.dsc"
> platforms support Xen guests, HVM only. They dynamically adapt to QEMU
> vs. Xen HVM.
>
> This dynamism has been a *huge* development and maintenance complication
> over the years. Another issue (which has been becoming ever more acute)
> is the NOOPT binary size, which certainly matters for debugging.
>
> With the introduction of OvmfXen in August 2019
> <https://bugzilla.tianocore.org/show_bug.cgi?id=1689>, we formed a plan
> to remove the dynamism. Xen guests would only be targeted with the
> OvmfXen platform, while the "historical three" would only target QEMU.
> See <https://bugzilla.tianocore.org/show_bug.cgi?id=2122>.
>
> The incompatibility is that an existing Xen guest that uses one of the
> "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc", "OvmfPkgX64.dsc" firmware
> binaries will have to be reconfigured on the host to switch to the
> "OvmfXen.dsc" binary, after an edk2 package upgrade brings the above
> change to the host.
>
> Anthony originally proposed a 1 year grace period; we're now at 23
> months. I've got 20 patches thus far, and those only take us about one
> third, or maybe one half, of the way. It's a very intrusive patch
> series, not one to revert after it's applied.
>
> My intent / hope is to get this merged into the (presumed)
> edk2-stable202108 tag. If you find that too early, please speak up.
>
> If you have another distro with LTS in mind whose package maintainer I
> should have put on the address list, please don't hesitate to add them.
>
> Please note that my question is not *if* we should do this, the question
> is *when* you can tolerate it, in your respective distros.
>

I have no stake in this, but I do strongly support this change. As
Laszlo points out, the maintenance burden is substantial, with very
little benefit.