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

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

[Cody Zuschlag]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

Hi everyone,

It's time for the August Xen Project Community Call, happening this
Thursday, 6 August at 15:00 UTC.

Whether you have updates to share or just want to listen in, we'd love to
have you join. It's a great opportunity to hear what the community has been
working on, discuss ongoing project activities, and catch up on recent
developments.

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

Want to be CC'd on future community call announcements?

Add or remove yourself from our sign-up sheet:
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

See you on Thursday!

Best regards,

Cody Zuschlag
Xen Project - Community Manager

[-- Attachment #2: Type: text/html, Size: 1982 bytes --]

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

[Elliott Mitchell]

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 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@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

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

[Roger Pau Monné]

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.