GSoC 2026: Introduction and Inquiry regarding "Porting Qubes to ARM/aarch64"

[Rohit Yadav]

Hello Marek Marczykowski-Górecki,

My name is Rohit Yadav, and I am writing to express my strong interest
in contributing to the "Porting Qubes to ARM/aarch64" project for GSoC
2026.

I am currently pursuing a Bachelor's degree in Electronics and
Communication Engineering, with a focus on operating systems, Computer
Architecture, embedded systems, and virtualization.

After reading through the ppc64 port thread (#4318) and the seL4
microkernel discussion (#3894), I understand that the project should
retain the Xen-based architecture and follow a phased integration
strategy.

My current plan for Phase 1 is to focus on cross-compiling a minimal,
headless dom0 environment that boots to a serial console, deferring
GUI and complex hardware integration to later stages.

I would appreciate guidance on a few architectural questions:

1. Should Phase 1 MVP validation be limited to QEMU-based emulation,
or should I need to do  ARM bare-metal testing? If yes then which
platform? In Power9/ppc64le Port they are doing the testing on
hardware.

2.For cross-compilation support, should I focus exclusively on
extending qubes-builderv2, or are there existing efforts or preferred
approaches I should align with?

3. For ARM device support, should the goal be to extend existing
device assignment mechanisms in qubes-core-admin, or introduce a
separate abstraction for platform devices?

4. For initial ARM bring-up, is there a preferred boot path (e.g.,
UEFI/SBBR vs U-Boot), or should I prioritize whichever approach allows
the simplest Xen + dom0 boot?

5. For qrexec and vchan on ARM, should I expect any known
architecture-specific issues, or is the current implementation largely
portable once the system boots?

6. Within the GSoC timeline, should the focus be on achieving a
minimal working ARM port (MVP), or is a more complete,
production-level system expected?

Thank you for your time, and I look forward to contributing to the project.

Best regards,

Rohit Yadav

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Mar 30, 2026 at 10:27:02AM -0700, Rohit Yadav wrote:
> Hello Marek Marczykowski-Górecki,

Hello,

> My name is Rohit Yadav, and I am writing to express my strong interest
> in contributing to the "Porting Qubes to ARM/aarch64" project for GSoC
> 2026.
>
> I am currently pursuing a Bachelor's degree in Electronics and
> Communication Engineering, with a focus on operating systems, Computer
> Architecture, embedded systems, and virtualization.
>
> After reading through the ppc64 port thread (#4318) and the seL4
> microkernel discussion (#3894), I understand that the project should
> retain the Xen-based architecture and follow a phased integration
> strategy.
>
> My current plan for Phase 1 is to focus on cross-compiling a minimal,
> headless dom0 environment that boots to a serial console, deferring
> GUI and complex hardware integration to later stages.
>
> I would appreciate guidance on a few architectural questions:
>
> 1. Should Phase 1 MVP validation be limited to QEMU-based emulation,
> or should I need to do ARM bare-metal testing? If yes then which
> platform? In Power9/ppc64le Port they are doing the testing on
> hardware.

For initial testing QEMU should be enough. At some point testing on real
hardware will be necessary, but I doubt the GSoC project would reach
such stage.

> 2.For cross-compilation support, should I focus exclusively on
> extending qubes-builderv2, or are there existing efforts or preferred
> approaches I should align with?

Cross-compilation support in qubes-builderv2 would be nice, but also
would be quite complex thing to do. A more realistic approach would be
to run qubes-builderv2 on a real ARM system and do a native build. Note
qubes-builderv2 doesn't need to run on qubes, or even in any virtual
machine (it can use containers instead), so it doesn't need Qubes OS to
build Qubes OS. I guess even running in QEMU may work, but would be
quite slow. If you don't have any Linux-capable ARM64 device, I probably
can arrange remote access to some (at least a Raspberry Pi 5, but maybe
something more powerful).

> 3. For ARM device support, should the goal be to extend existing
> device assignment mechanisms in qubes-core-admin, or introduce a
> separate abstraction for platform devices?

Definitely build on existing devices API. I guess it would mean a new
device type ("platform"?).

> 4. For initial ARM bring-up, is there a preferred boot path (e.g.,
> UEFI/SBBR vs U-Boot), or should I prioritize whichever approach allows
> the simplest Xen + dom0 boot?

This may differ between platforms, better inquire Xen developers (either
on a mailing list, or matrix). For the GSoC project, I'd say the latter
makes more sense, to not spend too much time on platform-specific
issues.

> 5. For qrexec and vchan on ARM, should I expect any known
> architecture-specific issues, or is the current implementation largely
> portable once the system boots?

Do you want theory or practice? ;) In theory vchan should just work. GUI
agent/daemon will likely not work out of the box, but I doubt it would
be in scope for GSoC timeline.

> 6. Within the GSoC timeline, should the focus be on achieving a
> minimal working ARM port (MVP), or is a more complete,
> production-level system expected?

I'd say achieving something that can build and start dom0 and maybe one
more qube (preferably sys-net, but more realistic would be some
device-less one) would be a realistic goal for GSoC timeline.
Of course if you manage to achieve more, I won't complain ;)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnLB0gACgkQ24/THMrX
1yzhowf/XO46/bcUlHj8VY6xWTEWtBhHFT8ppmYP9Zhs5KXF0+5j/9RBfqFU9uM6
ScRG3ChRLZc7u6seq6jUl+ofOXz9lbf8zD4/sUcTChXyoKaN48GlcqdGkVrWul0O
Yi7pvMuEzL9LT72CfzEynsGBNRMB4GUJAg1HrntW6BmJq6kdIgU/ClxP5ku3HkGj
RnQ1ATud6uQjdtYkArIFqGldkX16+I9HVrGm8jSDlLMp5c5ebFmx2ZiTsiS1WbzS
GermzgO3Zp7f7PDK3qKbBFuOuz+wPc8qsngOussDco9+b50EEFZn3EleXRdChdoD
n2Lq/xffeHcJAzJBKbCQ5iTHHx8bPw==
=uMnM
-----END PGP SIGNATURE-----

[Rohit Yadav]

Hi Marek,

I hope you're doing well.

I wanted to inform you that I unfortunately missed the GSoC proposal submission deadline despite preparing my proposal and incorporating your guidance.

I understand the importance of deadlines, but I wanted to ask if there is any possibility of submitting the proposal late, or if there are any alternative ways I can still contribute to this project under your guidance.

Regardless of the outcome, I remain very interested in working on the ARM port and would be happy to continue contributing outside of GSoC as well.

This is the Proposal - https://docs.google.com/document/d/1FJxjYO-cZBTXouOfRtBILJuJgGF2rvH1rKZPM1v3CGk/edit?usp=sharing

Thank you for your time and support.

Best regards,
Rohit Yadav

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Mar 31, 2026 at 11:28:18AM -0700, Rohit Yadav wrote:
>
>
> Hi Marek,
>
> I hope you're doing well.
>
> I wanted to inform you that I unfortunately missed the GSoC proposal
> submission deadline despite preparing my proposal and incorporating your
> guidance.
>
> I understand the importance of deadlines, but I wanted to ask if there is
> any possibility of submitting the proposal late, or if there are any
> alternative ways I can still contribute to this project under your guidance.

I'm afraid there isn't anything we can do here, it's not us who enforce
the deadline but GSoC coordinators at Google.

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/e00b7946-5294-4298-8f6c-d15de041234cn%40googlegroups.com.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnMR2cACgkQ24/THMrX
1ywe7gf/eRMpdCn/RoZmJrke1PqdtKAE3h28oa0L0D7wOt80gzT284fR14vDNIrc
au9KeHSE0ga23/kBBKjcJ5/VJxmzItVZvVoWNYhSw0+kkPibe1AkEgR9eUCxUm8d
XYvOHPr3iMyxi37BB4DTjlI9gzSjiEXf5yGYKXz7BHNr9NdxJQQ5dFdWBiEmoTeD
wqMWEtwgtse0ACeDo0+Dtx7nhc8EHrJvEs8rXjTcHenVVD2EtGplGtWR4cCN1oH/
avC7g9g1/h29d/ThP9Qe8kYkypv+03bholjVThQ1+OKihEdl0PxZ632W8GMFDJrj
ovXv7S9qJMuLdqEXoUepyaXXo8YRmA==
=JRpv
-----END PGP SIGNATURE-----