Mailing List Archive: Xen portability

Xen portability

Feb 2, 2024, 5:32 AM

Post #1 of 3 (73 views)

Hi Xen community,

I have a somewhat generic question about portability on Arm platforms.

I have been testing Xen on Armv8 using QEMU (with Linux as Dom0 and
also using OP-TEE), and it works fine. I then started to investigate
how portable Xen is among Arm platforms. According to the Xen wiki[1]
there are not many requirements on the hardware to get Xen to work (it
states that Xen only uses the GIC, generic timers, SMMU and a UART)
assuming one already has a functioning Linux with an appropriate DTB
(device tree).

On another Xen wiki page[2] I further get the impression that adding
Xen should be easy once Linux is up and running. The same page also
lists a number of platforms where Xen has been tested.

So my main question is, does that mean that I can expect Xen to work
with low effort on most Arm devices where I already have a functioning
Linux environment and Xen-compatible hardware (GIC, timers, SMMU,
UART)?

The reason for my doubt is that, I more or less arbitrarily started
looking at the NXP i.MX8MQ evaluation board. It has a DTB in Linux
mainline (arch/arm64/boot/dts/freescale/imx8mq-evk.dts), and it seems
to have a GICv3-compliant GIC which Xen supports. I do not know much
about timers, but the DTB states it has timers with compatible
"arm,armv8-timer" which sounds quite generic. I have not found
anything about SMMU and I probably need some UART driver, but it seems
manageable. However, NXP themselves say that they do not support Xen on
that board, but has support for the i.MX8QM board. They have their own
clone of the Xen git[3] for that board. When looking at that git, I see
that they have done quite a bit of changes to the Xen code, and a lot
of additions in form of new drivers. That gives me the impression that
it is not at all so easy to get Xen to work on any board, contrary to
the impression I got from the Xen wiki pages.

So I want to get a feeling for how much effort is usually required to
get Xen up and running on a new platform. Anyone who has some
experience with this, and what the most important things to look for
are when considering the suitability of a platform for Xen?

[1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper#Porting_Xen_to_a_new_SoC
[2] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
[3] https://github.com/nxp-imx/imx-xen

Re: Xen portability [ In reply to ]

Bertrand.Marquis at arm

Feb 5, 2024, 7:34 AM

Post #2 of 3 (69 views)

Permalink

Hi Boris,

> On 2 Feb 2024, at 13:32, FIXED-TERM Klintefjord Boris (XC-CP/ENG3-SE) <fixed-term.Boris.Klintefjord@se.bosch.com> wrote:
>
> Hi Xen community,
>
> I have a somewhat generic question about portability on Arm platforms.
>
> I have been testing Xen on Armv8 using QEMU (with Linux as Dom0 and
> also using OP-TEE), and it works fine. I then started to investigate
> how portable Xen is among Arm platforms. According to the Xen wiki[1]
> there are not many requirements on the hardware to get Xen to work (it
> states that Xen only uses the GIC, generic timers, SMMU and a UART)
> assuming one already has a functioning Linux with an appropriate DTB
> (device tree).
>
> On another Xen wiki page[2] I further get the impression that adding
> Xen should be easy once Linux is up and running. The same page also
> lists a number of platforms where Xen has been tested.
>
> So my main question is, does that mean that I can expect Xen to work
> with low effort on most Arm devices where I already have a functioning
> Linux environment and Xen-compatible hardware (GIC, timers, SMMU,
> UART)?

yes most devices do not need any changes to have Xen working but
sometime a new uart driver can be needed or some adaptations might
be required to provide access to non standard firmware functionalities
required by dom0 (usually something to let pass some firmware calls
from dom0 to set or configure clocks or voltages).

>
> The reason for my doubt is that, I more or less arbitrarily started
> looking at the NXP i.MX8MQ evaluation board. It has a DTB in Linux
> mainline (arch/arm64/boot/dts/freescale/imx8mq-evk.dts), and it seems
> to have a GICv3-compliant GIC which Xen supports. I do not know much
> about timers, but the DTB states it has timers with compatible
> "arm,armv8-timer" which sounds quite generic. I have not found
> anything about SMMU and I probably need some UART driver, but it seems
> manageable. However, NXP themselves say that they do not support Xen on
> that board, but has support for the i.MX8QM board. They have their own
> clone of the Xen git[3] for that board. When looking at that git, I see
> that they have done quite a bit of changes to the Xen code, and a lot
> of additions in form of new drivers. That gives me the impression that
> it is not at all so easy to get Xen to work on any board, contrary to
> the impression I got from the Xen wiki pages.

I think NXP is currently upstreaming some changes required for some
of their I.MX8 platforms and those are definitely limited to the parts I
mentioned before.
The tree you are pointing seem to be based on xen 4.10 which is quite
old.

>
> So I want to get a feeling for how much effort is usually required to
> get Xen up and running on a new platform. Anyone who has some
> experience with this, and what the most important things to look for
> are when considering the suitability of a platform for Xen?

It is hard to say because we cannot forsee all possible adaptations
that could be required but if you look at usual platforms (arm GIC and
timers), the changes are around UART (when not using something
already supported by Xen), firmware calls and SMMU (if needed as
depending on the use case, xen not supporting it and it being handled
directly in dom0 is possible).

As far as we know no platform required changes in other parts of Xen.

Regards
Bertrand

>
> [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper#Porting_Xen_to_a_new_SoC
> [2] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> [3] https://github.com/nxp-imx/imx-xen

Re: Xen portability [ In reply to ]

sstabellini at kernel

Feb 5, 2024, 2:33 PM

Post #3 of 3 (69 views)

Permalink

Hi Boris,

For any NXP-specific questions, I am CCing a couple of people working on
NXP platforms that might be able to advise.

In general, assuming:
- the board is using device tree
- the board has an IOMMU for which Xen has a driver (e.g. SMMUv3)
- the board has a UART for which Xen has a driver (e.g. PL011)

Xen should boot without issues. However, it can happen to see a problem
due to one of these requirments not being fully met.

Cheers,

Stefano

On Mon, 5 Feb 2024, Bertrand Marquis wrote:
> Hi Boris,
>
> > On 2 Feb 2024, at 13:32, FIXED-TERM Klintefjord Boris (XC-CP/ENG3-SE) <fixed-term.Boris.Klintefjord@se.bosch.com> wrote:
> >
> > Hi Xen community,
> >
> > I have a somewhat generic question about portability on Arm platforms.
> >
> > I have been testing Xen on Armv8 using QEMU (with Linux as Dom0 and
> > also using OP-TEE), and it works fine. I then started to investigate
> > how portable Xen is among Arm platforms. According to the Xen wiki[1]
> > there are not many requirements on the hardware to get Xen to work (it
> > states that Xen only uses the GIC, generic timers, SMMU and a UART)
> > assuming one already has a functioning Linux with an appropriate DTB
> > (device tree).
> >
> > On another Xen wiki page[2] I further get the impression that adding
> > Xen should be easy once Linux is up and running. The same page also
> > lists a number of platforms where Xen has been tested.
> >
> > So my main question is, does that mean that I can expect Xen to work
> > with low effort on most Arm devices where I already have a functioning
> > Linux environment and Xen-compatible hardware (GIC, timers, SMMU,
> > UART)?
>
> yes most devices do not need any changes to have Xen working but
> sometime a new uart driver can be needed or some adaptations might
> be required to provide access to non standard firmware functionalities
> required by dom0 (usually something to let pass some firmware calls
> from dom0 to set or configure clocks or voltages).
>
> >
> > The reason for my doubt is that, I more or less arbitrarily started
> > looking at the NXP i.MX8MQ evaluation board. It has a DTB in Linux
> > mainline (arch/arm64/boot/dts/freescale/imx8mq-evk.dts), and it seems
> > to have a GICv3-compliant GIC which Xen supports. I do not know much
> > about timers, but the DTB states it has timers with compatible
> > "arm,armv8-timer" which sounds quite generic. I have not found
> > anything about SMMU and I probably need some UART driver, but it seems
> > manageable. However, NXP themselves say that they do not support Xen on
> > that board, but has support for the i.MX8QM board. They have their own
> > clone of the Xen git[3] for that board. When looking at that git, I see
> > that they have done quite a bit of changes to the Xen code, and a lot
> > of additions in form of new drivers. That gives me the impression that
> > it is not at all so easy to get Xen to work on any board, contrary to
> > the impression I got from the Xen wiki pages.
>
> I think NXP is currently upstreaming some changes required for some
> of their I.MX8 platforms and those are definitely limited to the parts I
> mentioned before.
> The tree you are pointing seem to be based on xen 4.10 which is quite
> old.
>
> >
> > So I want to get a feeling for how much effort is usually required to
> > get Xen up and running on a new platform. Anyone who has some
> > experience with this, and what the most important things to look for
> > are when considering the suitability of a platform for Xen?
>
> It is hard to say because we cannot forsee all possible adaptations
> that could be required but if you look at usual platforms (arm GIC and
> timers), the changes are around UART (when not using something
> already supported by Xen), firmware calls and SMMU (if needed as
> depending on the use case, xen not supporting it and it being handled
> directly in dom0 is possible).
>
> As far as we know no platform required changes in other parts of Xen.