Agilex 5E HPS and Linux

Hi FPGABear,

Please review this page and see if it helps answer your questions: 

https://altera-fpga.github.io/rel-26.1/virtualization/hypervisors/xen/xen-overview/

Sue

Hi.

This isn't entirely a good solution unless you have an example of a "True Dom0-less" solution?

Aint no such thing as simple hps

Hi FPGABear​ 

Altera currently has a Traditional Xen Hypervisor example design for Agilex 5. Xen Dom0-less is currently not supported.

May I know more about your use case or application?

If your primary requirement is to split the CPU cores and run two independent Linux instances, with one Linux instance using 2×A55 cores and the other using 2×A76 cores, this can be achieved using the Traditional Xen Hypervisor example design supported on Agilex 5.

For the Ethernet requirement, if your application allows, using two Ethernet ports would simplify the configuration — one port can be assigned to Dom0 and the other to DomU in passthrough mode.
If you specifically need to share a single physical Ethernet port between the two Linux instances, virtual networking using Xen bridge can be considered.

In the 26.3 release, we are adding a lightweight static-partitioning hypervisor (Bao Hypervisor). It allows static partitioning of CPU cores and running different OS instances on different cores without requiring a management/privileged domain, similar to the Xen Dom0-less concept. However, device sharing/para-virtualization is not supported with this approach.

Nirav_Altera - "However, device sharing/para-virtualization is not supported with this approach." Does this mean that two separate Linux systems must be run on two different physical memories (DDR)?

Moreover, on github "Bao Hypervisor" they write that there is already support for Agilex 5.

Hi FPGABear​ 

No, that is not what it means — a single DDR is fine. "Static partitioning" here refers to address-space partitioning, not physically separate memory devices. Bao carves the one physical DRAM into non-overlapping regions, one per VM, and each guest only ever sees its own region. Isolation is enforced by the stage-2 MMU for CPU accesses, and by the SMMU for DMA-capable masters assigned to a VM. So your two Linux instances run out of the same DDR at different physical base addresses.

What "no device sharing / para-virtualization" refers to is the peripheral level. Because Bao has no privileged or backend domain, every peripheral is assigned exclusively to exactly one VM in passthrough — there is no netback/netfront-style split driver to multiplex a single controller between two guests. For your Ethernet question specifically:

- Two EMACs, one per VM: clean passthrough, no software in the datapath. This is the recommended option under Bao.
- If sharing one physical port through the virtualization layer is a hard requirement, traditional Xen with a bridge in Dom0 is the better option.

On GitHub: we have recently upstreamed Agilex 5 platform support to the Bao Hypervisor, and there is an ongoing effort to add examples for Linux + FreeRTOS configurations on Agilex 5. The distinction I was drawing is that current upstream support is not the same as an Altera-tested release — 26.3 is where you will get the validated example design and documentation.

So, for example, for two Linux systems, you can permanently assign a memory area (another area outside the systems area) with the same physical address, and set the paging of that area to the same size as the area's size?

Hi FPGABear​ 

Yes, that is broadly the right picture.

Under Bao, the mechanism is exactly what you describe: a third DDR carve-out, outside the RAM regions of both guests, declared statically in the Bao configuration and mapped into both VMs. It is real shared memory — one physical region, two mappings — not a copy on each side.

The address does not have to be identical in both guests. Each VM sees the region in its own intermediate physical address(IPA) space, and you are free to place it at different IPAs in VM1 and VM2. You do not need tconfigure the paging yourself. Bao sets up the stage-2 translation for the region.