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

["Roger Pau Monné" <roger@xenproject.org>]

On Mon, Aug 10, 2026 at 07:35:59PM -0700, Elliott Mitchell wrote:
> 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@mattapan.m5p.com/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 what you mean or imply with "accepted the task".  It
sounds a bit selfish to me that you refuse to finish the OVMF work.
It's possible none of us likes the OVMF coding style more than you do,
yet you seem to assume we have some kind of duty to pick this work and
finish it.  That's IMO an unacceptable burden to put on developers of
an open source project.

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

Anthony has done the work for OVMF to work on x86 PVH domains, maybe
he can provide more information about how to set it up and test.

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

In my opinion, it's naive to expect this plan to be realized without
any developer effort behind it from your side.  Leaving aside whether
it's the right call from a technical prospective, I don't think it's
fair to come to an Open Source community, drop a multi-project
multi-architecture plan, and expect others to simply start crunching
on it because "it's the right thing to do".

Most of us already have very thigh deadlines and internal projects by
our employers, and that's always going to take priority.  And then
with whatever little "free" time we have, we might have other goals
and tasks that prefer to pursuit.

In other words, I think if you want to see this making progress you
either have to work on it yourself, or pay some developer(s) to do the
work.

Regards, Roger.