deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in OvmfPkg

deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in OvmfPkg

[Laszlo Ersek]

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.

Thanks,
Laszlo

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

[Ard Biesheuvel]

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.