[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Xen portability
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. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |