Re: Xen portability

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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