Re: [ANNOUNCE] - Call for agenda items for August 6 Xen Community Call @ 15:00 UTC

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Tue, Aug 04, 2026 at 05:30:50PM +0200, Cody Zuschlag wrote:
> *Preparation*
> 
> 👉 Please take a few minutes to review and update the agenda before the
> call:
> 
> https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/
> 
> Feel free to:
> - Add topics or project updates
> - Suggest anything we can drop or defer
> - Include links to patches, mailing list threads, or documentation where
> helpful
> 
> The agenda also includes the meeting link and a link to find your local
> meeting time.
> 
> 
> *Call Details*
> Date: Thursday, 6 August 2026
> Time: 15:00 UTC (agenda starts at 15:05 UTC)
> Join: https://meet.jit.si/XenProjectCommunityCall
> 
> We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give
> everyone a few minutes to join.


Took me a bit of time to consider what had been said in order to come up
with next responses.

I didn't emphasize it during the community call, but the point was
explicit in the most recent posted message:

https://lore.kernel.org/xen-devel/ajr0gN9kmPkLQlGF@xxxxxxxxxxxxxxxx/T/

This was previously allowed by Xen/ARM.  This turned into a bug when the
Xen/ARM team decided to disallow multiple mappings of the shared
information page.  During approval the Xen/ARM team was explicitly asked
to accept the task of updating outside projects to deal with fall-out.

I don't recall the exact wording of the agreement, but this is certainly
fall-out from that change.  As such this IS an adjustment the Xen/ARM
team agreed to aid.

I've already generated a PoC, I had thought the Xen/ARM team would be
better acquainted with whom to ask about getting a patch along those
lines in.  That seems a reasonable ask in light of the team having
accepted the task.



I don't know the Xen developers by voice.  As such I don't know who
mentioned 'firmware = "ovmf"' when I was trying to bring up
Tianocore/EDK2 as bootloader.  Now that I've checked by notes, whomever
brought that up was quite unfamiliar with that I was trying to bring up.

The 'firmware = "ovmf"' setting is part of HVM domain configuration.  In
this environment Tianocore/EDK2 is merely setting up some ACPI tables and
then handling the task of finding and invoking the OS bootloader.  Since
all the hardware is emulated, Tianocore/EDK2-firmware isn't much
different from what it normally does.  I should also note this is fairly
slow.

Despite sharing the codebase, Tianocore/EDK2 as bootloader is very
different from being HVM firmware.  In particular the arm64
Tianocore/EDK2 configuration is "ArmVirtPkg/ArmVirtXen.dsc" and the build
creates the file "XEN_EFI.fd".  Once built the domain configuration is
along the lines of:

type = "pvh"
name = "somename"
kernel = "XEN_EFI.fd"
memory = 256
vcpus = 2
vif = [ "somenet" ]
disk = [ "somedisk" ]

The result is a PVH domain with Tianocore/EDK2 functioning as a pure
bootloader.  In particular it is capable of searching for its preferred
filesystem, then looking for an appropriate filename and then loading
that using the UEFI protocol.  The result is near-ideal.

Of note I'm pretty sure Tianocore/EDK2-bootloader would happily load
EFI-GRUB.  More importantly though OS bootloaders which can handle UEFI
work perfectly in this setup.  I expect this to be superior for *BSD.

There are two problems with Tianocore/EDK2-bootloader though.  First, is
the aforementioned unresolved bug.  Second, this is only implemented for
aarch64 (arm64).

This is a problem for all the paravirtualized bootloaders.  They're all
single-architecture, despite the bootloader supporting multiple
architectures.  On that single-architecture they're quite good, but Xen
really needs them on *all* their architectures.


I didn't get the chance to finish my suggestion during the call, so here
is what I wanted to suggest:

I think the Xen Project really needs some effort aimed at the
paravirtualized bootloaders.  Mostly making them operable on all
architectures they support.

Paravirtualized GRUB is needed for ARM, RISC-V and PowerPC.

I don't believe Tianocore/EDK2 supports PowerPC, but I would really hope
for it to become available for RISC-V and x86.

While U-Boot is difficult to deal with, it would be valuable as a second
paravirtualized bootloader for PowerPC.

Once those 3 were available on their applicable architecture it would be
time to purge PyGRUB.  While I imagine this will take a while I think it
should be on the roadmap/panciled in for the future.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445