https://wiki.xenproject.org/api.php?action=feedcontributions&user=StefanoStabellini&feedformat=atomXen - User contributions [en]2024-03-28T10:10:13ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=File:Cachecoloring.png&diff=19990File:Cachecoloring.png2022-10-07T00:01:15Z<p>StefanoStabellini: </p>
<hr />
<div></div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=File:Null.png&diff=19989File:Null.png2022-10-07T00:01:03Z<p>StefanoStabellini: </p>
<hr />
<div></div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Test_page&diff=19988Test page2022-10-07T00:00:40Z<p>StefanoStabellini: </p>
<hr />
<div>= Xen as Static Partitioning Hypervisor for Embedded and Automotive =<br />
<br />
You might already know that Xen powers some of the largest clouds in production today, but did you know that Xen is also an excellent static partitioning hypervisor for embedded applications?<br />
<br />
Xen can be configured for embedded '''static partitioning''' using '''Dom0less''' and the '''null scheduler'''.<br />
<br />
'''Dom0less''' enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions.<br />
<br />
[[File:Dom0less.png]]<br />
<br />
Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to [https://gitlab.com/xen-project/imagebuilder ImageBuilder].<br />
<br />
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you.<br />
<br />
[[File:null.png]]<br />
<br />
Use Dom0less and the null scheduler together to achieve a true static partitioning configuration.<br />
<br />
<br />
= Cache Coloring and Deterministic Interrupt Latency =<br />
<br />
If you need fully deterministic interrupt latency and hard real-time, a shared L2 cache across CPU cores can be a vehicle for interference. Xen solves the problem by splitting the L2 cache in software using a technology called "Cache Coloring". Xen with Cache Coloring has a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+, even under heavy interference from multiple sources.<br />
<br />
[[File:cachecoloring.png]]<br />
<br />
Checkout the original [https://www.youtube.com/watch?v=KhESjhUzyj8 Cache Coloring presentation] for more details.<br />
<br />
<br />
= Xen Safety-Certifications =<br />
<br />
Multiple safety assessors from well-known companies in the safety industry have evaluated Xen and deemed it safety-certifiable.<br />
<br />
If you are interested in safety certifications, join the [https://lists.xenproject.org/mailman/listinfo/fusa-sig Xen FuSa Special Interest Group] or watch one of the [https://wiki.xenproject.org/wiki/FuSa_SIG/Presentations latest presentations].<br />
<br />
The Xen FuSa SIG has the specific goal of making upstream Xen releases easier to safety certify. The working group is active in a number of areas, from documentation to testing and traceability. Specific examples of Xen FuSa SIG activities are MISRA C compatibility improvements and the introduction of more tests to validate Xen external interfaces.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Test_page&diff=19987Test page2022-10-06T23:56:15Z<p>StefanoStabellini: </p>
<hr />
<div>= Xen as Static Partitioning Hypervisor for Embedded and Automotive =<br />
<br />
You might already know that Xen powers some of the largest clouds in production today, but did you know that Xen is also an excellent static partitioning hypervisor for embedded applications?<br />
<br />
Xen can be configured for embedded '''static partitioning''' using '''Dom0less''' and the '''null scheduler'''.<br />
<br />
'''Dom0less''' enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions.<br />
<br />
[[File:Dom0less.jpg]]<br />
<br />
Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to [https://gitlab.com/xen-project/imagebuilder ImageBuilder].<br />
<br />
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you.<br />
<br />
Use Dom0less and the null scheduler together to achieve a true static partitioning configuration.<br />
<br />
<br />
= Cache Coloring and Deterministic Interrupt Latency =<br />
<br />
If you need fully deterministic interrupt latency and hard real-time, a shared L2 cache across CPU cores can be a vehicle for interference. Xen solves the problem by splitting the L2 cache in software using a technology called "Cache Coloring". Xen with Cache Coloring has a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+, even under heavy interference from multiple sources.<br />
<br />
Checkout the original [https://www.youtube.com/watch?v=KhESjhUzyj8 Cache Coloring presentation] for more details.<br />
<br />
<br />
= Xen Safety-Certifications =<br />
<br />
Multiple safety assessors from well-known companies in the safety industry have evaluated Xen and deemed it safety-certifiable.<br />
<br />
If you are interested in safety certifications, join the [https://lists.xenproject.org/mailman/listinfo/fusa-sig Xen FuSa Special Interest Group] or watch one of the [https://wiki.xenproject.org/wiki/FuSa_SIG/Presentations latest presentations].<br />
<br />
The Xen FuSa SIG has the specific goal of making upstream Xen releases easier to safety certify. The working group is active in a number of areas, from documentation to testing and traceability. Specific examples of Xen FuSa SIG activities are MISRA C compatibility improvements and the introduction of more tests to validate Xen external interfaces.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=File:Dom0less.png&diff=19986File:Dom0less.png2022-10-06T23:44:28Z<p>StefanoStabellini: </p>
<hr />
<div></div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Test_page&diff=19985Test page2022-10-06T23:10:27Z<p>StefanoStabellini: </p>
<hr />
<div>= Xen as Static Partitioning Hypervisor for Embedded and Automotive =<br />
<br />
Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' and the '''null scheduler'''.<br />
<br />
'''Dom0less''' enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions. Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to [https://gitlab.com/xen-project/imagebuilder ImageBuilder].<br />
<br />
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you.<br />
<br />
<br />
= Cache Coloring and Deterministic Interrupt Latency =<br />
<br />
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+ even under heavy interference from multiple sources.<br />
<br />
Checkout the original [https://www.youtube.com/watch?v=KhESjhUzyj8 Cache Coloring presentation] for more details.<br />
<br />
<br />
= Xen Safety-Certifications =<br />
<br />
Xen is safety-certifiable, as stated by multiple well-respected safety assessors in the safety industry. However, work is required to take an upstream Xen release and safety-certify it. There is an active working group, named Xen FuSa SIG (Special Interest Group), with the goal of making upstream Xen releases easier to safety-certify by users and other downstreams. The Xen FuSa SIG is working on a number of activities to better align upstream Xen with safety requirements, including documentation and testing. Currently the Xen FuSa SIG is improving MISRA C compatibility of the Xen codebase and introducing more tests to validate Xen external interfaces.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Test_page&diff=19984Test page2022-10-06T23:07:04Z<p>StefanoStabellini: </p>
<hr />
<div>= Xen as Static Partitioning Hypervisor for Embedded and Automotive =<br />
<br />
Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' and the '''null scheduler'''.<br />
<br />
'''Dom0less''' enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions. Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to [[ImageBuilder|https://gitlab.com/xen-project/imagebuilder]].<br />
<br />
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you.<br />
<br />
<br />
= Cache Coloring and Deterministic Interrupt Latency =<br />
<br />
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+ even under heavy interference from multiple sources.<br />
<br />
Checkout the original [[Cache Coloring presentation|https://www.youtube.com/watch?v=KhESjhUzyj8]] for more details.<br />
<br />
<br />
= Xen Safety-Certifications =<br />
<br />
Xen is safety-certifiable, as stated by multiple well-respected safety assessors in the safety industry. However, work is required to take an upstream Xen release and safety-certify it. There is an active working group, named Xen FuSa SIG (Special Interest Group), with the goal of making upstream Xen releases easier to safety-certify by users and other downstreams. The Xen FuSa SIG is working on a number of activities to better align upstream Xen with safety requirements, including documentation and testing. Currently the Xen FuSa SIG is improving MISRA C compatibility of the Xen codebase and introducing more tests to validate Xen external interfaces.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Test_page&diff=19983Test page2022-10-06T22:59:19Z<p>StefanoStabellini: Created page with "= Xen as Static Partitioning Hypervisor for Embedded and Automotive = Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' a..."</p>
<hr />
<div>= Xen as Static Partitioning Hypervisor for Embedded and Automotive =<br />
<br />
Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' and the '''null scheduler'''.<br />
<br />
Dom0less enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions. Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to ImageBuilder.<br />
<br />
The null scheduler is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency.<br />
<br />
<br />
= Cache Coloring and Deterministic Interrupt Latency =<br />
<br />
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+ even under heavy interference from multiple sources.<br />
<br />
<br />
= Xen Safety-Certifications =<br />
<br />
Xen is already safety-certifiable, as stated by multiple well-respected safety assessors in the safety industry. There is an active working group, named Xen FuSa SIG, with the goal of making upstream Xen releases easier to safety-certify by users and better aligned with safety requirements. Currently the Xen FuSa SIG is improving MISRA C compatibility of the Xen codebase and introducing more tests to validate Xen external interfaces.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19981FuSa SIG/Contributing2022-08-11T22:54:15Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings | FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel xen-devel] list following the [[Submitting_Xen_Project_Patches | Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck* (needs to be version 2.7 or greater):<br />
<br />
cd xen.git/xen/<br />
export CPPCHECK=/path/to/cppcheck/cppcheck<br />
export CPPCHECK_HTMLREPORT=/path/to/cppcheck/htmlreport/cppcheck-htmlreport<br />
export CPPCHECK_MISRA=y<br />
make cppcheck-html<br />
<br />
The output will be under *cppcheck-htmlreport/index.html* by default.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING | here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/gitlab-ci/test.yaml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing, especially static configuration features (e.g. dom0less and related configurations). For instance:<br />
* Boot Time Cpupools: https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/arm/device-tree/cpupools.txt</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19980FuSa SIG/Contributing2022-08-11T22:51:55Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings | FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel xen-devel] list following the [[Submitting_Xen_Project_Patches | Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck* (needs to be version 2.7 or greater):<br />
<br />
cd xen.git/xen/<br />
export CPPCHECK=/path/to/cppcheck/cppcheck<br />
export CPPCHECK_HTMLREPORT=/path/to/cppcheck/htmlreport/cppcheck-htmlreport<br />
export CPPCHECK_MISRA=y<br />
make cppcheck-html<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING | here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/gitlab-ci/test.yaml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing, especially static configuration features (e.g. dom0less and related configurations). For instance:<br />
* Boot Time Cpupools: https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/arm/device-tree/cpupools.txt</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19979FuSa SIG/Contributing2022-08-11T22:47:41Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings | FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel xen-devel] list following the [[Submitting_Xen_Project_Patches | Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck*.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING | here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/gitlab-ci/test.yaml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing, especially static configuration features (e.g. dom0less and related configurations). For instance:<br />
* Boot Time Cpupools: https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/arm/device-tree/cpupools.txt</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19978FuSa SIG/Contributing2022-08-11T22:44:48Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings | FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel xen-devel] list following the [[Submitting_Xen_Project_Patches | Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck*.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING | here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing. For instance [https://patchwork.kernel.org/project/xen-devel/cover/20220421081645.40235-1-luca.fancellu@arm.com/ Boot Time Cpupools].</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19977FuSa SIG/Contributing2022-08-11T22:41:31Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel | xen-devel] list following the [[Submitting_Xen_Project_Patches Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst| rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck*.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c| for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING| here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation| automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing. For instance [https://patchwork.kernel.org/project/xen-devel/cover/20220421081645.40235-1-luca.fancellu@arm.com/| Boot Time Cpupools].</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19976FuSa SIG/Contributing2022-08-11T22:41:01Z<p>StefanoStabellini: </p>
<hr />
<div>Join the [[FuSa_SIG/Meetings | FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen | xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel | xen-devel] list following the [[Submitting_Xen_Project_Patches | Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html | this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst| rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck*.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c| for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING| here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation| automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing. For instance [https://patchwork.kernel.org/project/xen-devel/cover/20220421081645.40235-1-luca.fancellu@arm.com/| Boot Time Cpupools].</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Contributing&diff=19975FuSa SIG/Contributing2022-08-11T22:40:17Z<p>StefanoStabellini: Created page with "Join the FuSa SIG meetings to participate in safety improvements for Xen. In this page we can find a list of small items for newcomers and seasoned con..."</p>
<hr />
<div>Join the [[FuSa_SIG/Meetings| FuSa SIG meetings]] to participate in safety improvements for Xen.<br />
<br />
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor ([https://gitlab.com/xen-project/xen/-/tree/staging/xen| xen subdirectory]).<br />
<br />
Please send fixes to the [https://lists.xenproject.org/mailman/listinfo/xen-devel| xen-devel] list following the [[Submitting_Xen_Project_Patches| Xen contribution process]]. For instance, see [https://lists.xenproject.org/archives/html/xen-devel/2022-08/msg00513.html| this example].<br />
<br />
<br />
= MISRA C =<br />
<br />
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst| rules.rst]<br />
<br />
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck*.<br />
<br />
Your help to reduce MISRA C violations in Xen is very welcome!<br />
<br />
<br />
= SPDX =<br />
<br />
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, [https://gitlab.com/xen-project/xen/-/blob/staging/xen/drivers/passthrough/arm/smmu-v3.c| for example]:<br />
<br />
// SPDX-License-Identifier: GPL-2.0<br />
<br />
<br />
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available [https://gitlab.com/xen-project/xen/-/blob/staging/COPYING| here].<br />
<br />
<br />
= Testing =<br />
<br />
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under [https://gitlab.com/xen-project/xen/-/tree/staging/automation| automation]:<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml<br />
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh <br />
<br />
Please add new tests for any features that you see missing. For instance [https://patchwork.kernel.org/project/xen-devel/cover/20220421081645.40235-1-luca.fancellu@arm.com/| Boot Time Cpupools].</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19974FuSa SIG/Status2022-08-11T22:21:00Z<p>StefanoStabellini: </p>
<hr />
<div>= Scope Definition =<br />
* Hardware<br />
** Platform core components (no platform drivers): timer, mmu, iommu, irq controller<br />
<br />
* System configuration<br />
** Dom0less<br />
** Mixed criticality: a certifiable VM and a non-certifiable VM<br />
<br />
= Ongoing Efforts =<br />
<br />
* Requirements and documentation<br />
** Doxygen for documentation of internal and external interfaces<br />
** Doorstop to link documentation and requirements to code<br />
** Zephyr solution (originally by Intel) based on Doxygen<br />
** In Progress: conversion of hypercalls docs to Doxygen format<br />
<br />
* MISRA C<br />
** MISRA C Working Group established<br />
** MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style.<br />
** [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst|MISRA C rules officially accepted in Xen]<br />
** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*<br />
** In Progress: violations reduction and MISRA C rules acceptance<br />
<br />
* Static System Definition<br />
** Static memory allocation<br />
** Static heap allocation<br />
** Static cpupools<br />
** Done: cpupools<br />
** In Progress: memory and heap allocation<br />
<br />
* Determinism and interference reduction<br />
** Interrupt latency analysis in Xen<br />
** Cache Coloring<br />
** In Progress: Cache Coloring upstreaming<br />
<br />
* Traceability<br />
** Trace review comments and patch versions all the way to a commit<br />
** Status: script prototype available to retrieve all mailing list discussions from a commit id<br />
<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19973FuSa SIG/Status2022-08-11T22:13:39Z<p>StefanoStabellini: </p>
<hr />
<div>= Scope Definition =<br />
* Hardware<br />
** Only platform core components (no platform drivers)<br />
*** timer, mmu, iommu, irq controller<br />
** board/platform specific code to be done by user<br />
<br />
* System configuration<br />
** Dom0less<br />
** Mixed criticality (a certifiable VM and a non-certifiable VM)<br />
<br />
= Ongoing Efforts =<br />
<br />
* Requirements format (doxygen)<br />
** table of requirements followed/to be followed/not applicable<br />
** doorstop (links requirements to code)<br />
** Zephyr solution (originally by Intel) based on doxygen<br />
** Challenge: all changes required within 1 release cycle. ACTION: plan out the activities with the committers.<br />
<br />
* MISRA C<br />
** MISRA C working group is evaluating MISRA C rules and accepting them into the Xen coding style.<br />
** [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst|MISRA C rules accepted in Xen]<br />
** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*<br />
** In progress: violations reduction<br />
<br />
* static system definition<br />
** static memory allocation<br />
** static heap allocation<br />
** cpupools<br />
** status: upstraming in progress<br />
<br />
* Real-time and interference reduction<br />
** real time analysis of Xen<br />
*** interrupt forward response time<br />
** cache coloring<br />
** status: upstreaming in progress<br />
<br />
* commit review tracing<br />
** get info from mailing list archive<br />
** script available to retrieve all mailing list discussions from a commit id<br />
<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Presentations&diff=19972FuSa SIG/Presentations2022-08-11T22:06:39Z<p>StefanoStabellini: </p>
<hr />
<div>= 2022 =<br />
<br />
Critical Summit North America 2022 [https://www.slideshare.net/StefanoStabellini/xen-in-safetycritical-systems-critical-summit-2022 | Xen in Safety-Critical Systems]<br />
<br />
= 2021 =<br />
<br />
Embedded & IoT World 2021 [https://iotseries.app.swapcard.com/event/embedded-iot-world/planning/UGxhbm5pbmdfMzkyMDgx | Panel Discussion - Safety certification in the open: How the Xen project is making progress to achieve certification] (registration needed to view content)<br />
<br />
ELISA Workshop May 2021 [https://elisaworkshopmay2021.sched.com/event/j3SO/functional-safety-at-xen-project-artem-mygaiev-epam-systems-stefano-stabellini-xilinx?iframe=no | Functional Safety at Xen Project]<br />
<br />
Xen Developer Summit 2021 [https://xen2021.sched.com/event/jAF1/xen-fusa-sig-updates-artem-mygaiev-epam-systems-stefano-stabellini-xilinx | Xen FuSa SIG updates]<br />
<br />
[[Category:Safety Certification/FuSa SIG]] [[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Presentations&diff=19970FuSa SIG/Presentations2022-08-11T22:04:46Z<p>StefanoStabellini: StefanoStabellini moved page FiSa SIG/Presentations to FuSa SIG/Presentations</p>
<hr />
<div><br />
= 2021 =<br />
<br />
Embedded & IoT World 2021 [https://iotseries.app.swapcard.com/event/embedded-iot-world/planning/UGxhbm5pbmdfMzkyMDgx | Panel Discussion - Safety certification in the open: How the Xen project is making progress to achieve certification] (registration needed to view content)<br />
<br />
ELISA Workshop May 2021 [https://elisaworkshopmay2021.sched.com/event/j3SO/functional-safety-at-xen-project-artem-mygaiev-epam-systems-stefano-stabellini-xilinx?iframe=no | Functional Safety at Xen Project]<br />
<br />
Xen Developer Summit 2021 [https://xen2021.sched.com/event/jAF1/xen-fusa-sig-updates-artem-mygaiev-epam-systems-stefano-stabellini-xilinx | Xen FuSa SIG updates]<br />
<br />
[[Category:Safety Certification/FuSa SIG]] [[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FiSa_SIG/Presentations&diff=19971FiSa SIG/Presentations2022-08-11T22:04:46Z<p>StefanoStabellini: StefanoStabellini moved page FiSa SIG/Presentations to FuSa SIG/Presentations</p>
<hr />
<div>#REDIRECT [[FuSa SIG/Presentations]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19969FuSa SIG/Status2022-08-11T21:50:07Z<p>StefanoStabellini: /* Scope Definition */</p>
<hr />
<div>= Scope Definition =<br />
* Hardware<br />
** Only platform core code (no driver)<br />
*** timer, mmu, iommu, irq controller<br />
** board/platform specific code to be done by user<br />
<br />
* System configuration<br />
** Dom0less<br />
** Mixed criticality (a certifiable VM and a non-certifiable VM)<br />
<br />
= Ongoing Efforts =<br />
<br />
* Requirements format (doxygen)<br />
** table of requirements followed/to be followed/not applicable<br />
** doorstop (links requirements to code)<br />
** Zephyr solution (originally by Intel) based on doxygen<br />
A bunch of work was done but more work is required. Request to change all the existing docs into doxygen.<br />
Issue is we only have 1 release cycle to switch to doxygen.<br />
What is the agreement / process to make progress on this? We don't want an 80 patches patch series.<br />
ACTION: bring the topic of the *process* up with the REST<br />
<br />
* Unclear coding style<br />
Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl.<br />
It needs to have a checker.<br />
It should be a well done well maintained project and coding style.<br />
Can we find a coding style similar to Xen coding style?<br />
It should work with standard editors.<br />
Can we agree on 2-3 parameters we can use to evaluate coding style?<br />
Are there FuSa friendly factors to consider?<br />
ACTION: bring up adoption of existing coding style<br />
<br />
* Misra requirement classification<br />
Marketing. Why the standards are there and why they can be useful. Code quality, testability, security.<br />
Agree on process: step by step starting from the non-controversial.<br />
ACTION: prepare a webminar 1-2 months (option to use LF webinar)<br />
ACTION: write emails status updates once a quarter<br />
ACTION: keynote at XenSummit<br />
<br />
* First status update:<br />
Misra rules already covered<br />
cppcheck that we want to add to Xen<br />
how much is already covered, burn down on what we want to do<br />
publish real-time capabilities analysis<br />
<br />
* Define actionable work packages for any contributors and maintainers<br />
<br />
* static code analysis (cppcheck, Coverity, Eclair)<br />
** goal: Misra code compliance<br />
<br />
* Real-time and interference reduction<br />
** real time analysis of Xen<br />
*** interrupt forward response time<br />
** cache coloring<br />
<br />
* commit review tracing<br />
** get info from mailing list archive<br />
<br />
* static system definition<br />
** static memory allocation<br />
** static heap allocation<br />
** cpupools<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19957FuSa SIG/Status2022-03-21T17:01:09Z<p>StefanoStabellini: /* Ongoing Efforts */</p>
<hr />
<div>= Scope Definition =<br />
* Hardware<br />
** Only platform core code (no driver)<br />
*** timer, mmu, irq controller<br />
** board/platform specific code to be done by user of Xen at this stage<br />
** PCI passthrough out of scope (for now)<br />
<br />
* System configuration<br />
** dom0less<br />
** Mixed criticality (a certifiable VM and a non-certifiable VM)<br />
<br />
= Ongoing Efforts =<br />
<br />
* Requirements format (doxygen)<br />
** table of requirements followed/to be followed/not applicable<br />
** doorstop (links requirements to code)<br />
** Zephyr solution (originally by Intel) based on doxygen<br />
A bunch of work was done but more work is required. Request to change all the existing docs into doxygen.<br />
Issue is we only have 1 release cycle to switch to doxygen.<br />
What is the agreement / process to make progress on this? We don't want an 80 patches patch series.<br />
ACTION: bring the topic of the *process* up with the REST<br />
<br />
* Unclear coding style<br />
Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl.<br />
It needs to have a checker.<br />
It should be a well done well maintained project and coding style.<br />
Can we find a coding style similar to Xen coding style?<br />
It should work with standard editors.<br />
Can we agree on 2-3 parameters we can use to evaluate coding style?<br />
Are there FuSa friendly factors to consider?<br />
ACTION: bring up adoption of existing coding style<br />
<br />
* Misra requirement classification<br />
Marketing. Why the standards are there and why they can be useful. Code quality, testability, security.<br />
Agree on process: step by step starting from the non-controversial.<br />
ACTION: prepare a webminar 1-2 months (option to use LF webinar)<br />
ACTION: write emails status updates once a quarter<br />
ACTION: keynote at XenSummit<br />
<br />
* First status update:<br />
Misra rules already covered<br />
cppcheck that we want to add to Xen<br />
how much is already covered, burn down on what we want to do<br />
publish real-time capabilities analysis<br />
<br />
* Define actionable work packages for any contributors and maintainers<br />
<br />
* static code analysis (cppcheck, Coverity, Eclair)<br />
** goal: Misra code compliance<br />
<br />
* Real-time and interference reduction<br />
** real time analysis of Xen<br />
*** interrupt forward response time<br />
** cache coloring<br />
<br />
* commit review tracing<br />
** get info from mailing list archive<br />
<br />
* static system definition<br />
** static memory allocation<br />
** static heap allocation<br />
** cpupools<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Roadmap&diff=19956FuSa SIG/Roadmap2022-03-15T01:59:54Z<p>StefanoStabellini: Created page with "= Short term Roadmap and ongoing activities = * Misra compliance ** ongoing: ** Coverity regular analysis (arm) *** CI internal checks ** cppcheck i..."</p>
<hr />
<div>= Short term Roadmap and ongoing activities =<br />
* Misra compliance<br />
** ongoing:<br />
** Coverity regular analysis (arm)<br />
*** CI internal checks<br />
** cppcheck integration in Xen (arm)<br />
*** cppcheck is buggy, could use clang? or a gcc sanitizer ?<br />
** classify the rules we want to support<br />
** to do:<br />
*** create list of rules and put a file in xen.git<br />
**** mention the status of each rule on the list<br />
*** list the rules already covered by current coding style<br />
*** updating the coding style<br />
*** regular checks on gitlab<br />
*** classify the rules in order of priority<br />
*** fix the Misra-C issues<br />
*** mention the Misra rule fixed when fixing findings<br />
** for the future<br />
*** submitted patch checks<br />
<br />
<br />
= Roadmap =<br />
<br />
* Zephyr as Dom0<br />
** tools license issue<br />
** what functionalities do we actually need ?<br />
* Configuration<br />
** per-domain Xen heap static allocation<br />
** configurability (strip down code)<br />
* Real-time<br />
** communication LinuxRT - Zephyr<br />
** code improvements<br />
*** remove RCU<br />
* Code quality<br />
** Misra-C compliance<br />
*** automatic checks on builds<br />
*** check on patches submitted<br />
*** include the rules in the coding style<br />
** use of a certified compiler<br />
* Documentation and requirements<br />
** process for change requests of reqs<br />
* Tests<br />
** traceability<br />
** coverage<br />
** low level testing</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19955FuSa SIG/Status2022-03-15T01:53:15Z<p>StefanoStabellini: </p>
<hr />
<div>= Scope Definition =<br />
* Hardware<br />
** Only platform core code (no driver)<br />
*** timer, mmu, irq controller<br />
** board/platform specific code to be done by user of Xen at this stage<br />
** PCI passthrough out of scope (for now)<br />
<br />
* System configuration<br />
** dom0less<br />
** Mixed criticality (a certifiable VM and a non-certifiable VM)<br />
<br />
= Ongoing Efforts =<br />
<br />
* Requirements format (doxygen)<br />
<br />
* Misra requirement classification<br />
** table of requirements followed/to be followed/not applicable<br />
** doorstop (links requirements to code)<br />
** Zephyr solution (originally by Intel) based on doxygen<br />
<br />
* static code analysis (cppcheck, Coverity, Eclair)<br />
** goal: Misra code compliance<br />
<br />
* Real-time and interference reduction<br />
** real time analysis of Xen<br />
*** interrupt forward response time<br />
** cache coloring<br />
<br />
* commit review tracing<br />
** get info from mailing list archive<br />
<br />
* static system definition<br />
** static memory allocation<br />
** static heap allocation<br />
** cpupools<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&diff=19954FuSa SIG/Status2022-03-15T01:50:29Z<p>StefanoStabellini: Created page with "= Ongoing Efforts = * Requirements format (doxygen) * Misra requirement classification ** table of requirements followed/to be followed/not applicable ** doorstop (links req..."</p>
<hr />
<div>= Ongoing Efforts =<br />
<br />
* Requirements format (doxygen)<br />
<br />
* Misra requirement classification<br />
** table of requirements followed/to be followed/not applicable<br />
** doorstop (links requirements to code)<br />
** Zephyr solution (originally by Intel) based on doxygen<br />
<br />
* static code analysis (cppcheck, Coverity, Eclair)<br />
** goal: Misra code compliance<br />
<br />
* Real-time and interference reduction<br />
** real time analysis of Xen<br />
*** interrupt forward response time<br />
** cache coloring<br />
<br />
* commit review tracing<br />
** get info from mailing list archive<br />
<br />
* static system definition<br />
** static memory allocation<br />
** static heap allocation<br />
** cpupools<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Category:Safety_Certification/FuSa_SIG&diff=19953Category:Safety Certification/FuSa SIG2022-03-15T01:46:17Z<p>StefanoStabellini: </p>
<hr />
<div>This category contains pages related to the '''Xen FuSa Special Interest Group'''. This page has changed significantly in 2019, when we archived most of the PV Driver related activity, which has been mostly completed. The new focus are '''mixed-criticality systems''' with the capability of being able to safety certify Xen.<br />
{{Trailbox|FuSa SIG|FuSa_SIG<br />
|{{Trail|Key pages|<br />
* [http://xenproject.org/developers/teams/embedded-and-automotive.html Project Portal]<br />
* [[FuSa SIG/Charter|Charter]]<br />
* [[FuSa SIG/Meetings|Meetings]]<br />
* [[FiSa SIG/Presentations|Presentations]]<br />
}}|{{Trail|Status and Roadmap|<br />
* [[FuSa SIG/Status|Status]]<br />
* [[FuSa SIG/Roadmap|Roadmap]]<br />
}}|{{Trail|Resources|<br />
* [https://lists.xenproject.org/cgi-bin/mailman/listinfo/fusa-sig fusa-sig@ mailing list ]<br />
}}<br />
}}<br />
<br />
== New Pages ==<br />
Name new pages<br />
<pre>FuSa SIG/<topic></pre><br />
Use at the bottom of new pages for this category<br />
<pre>[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</pre><br />
Importing google docs content:<br />
* Step 1: Copy google docs text into [https://html-cleaner.com/ html-cleaner.com] <br />
* Step 2: Select the following options, then convert and copy the content into the clipboard: remove inline styles, remove classes and IDs, remove span tags, remove comments, encode special characters)<br />
* Step 3: Use [https://foliovision.com/seo-tools/pandoc-online# foliovision.com/seo-tools/pandoc-online] and convert from HTML to Mediawiki</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Category:Safety_Certification/FuSa_SIG&diff=19952Category:Safety Certification/FuSa SIG2022-03-15T01:43:18Z<p>StefanoStabellini: </p>
<hr />
<div>This category contains pages related to the '''Xen FuSa Special Interest Group'''. This page has changed significantly in 2019, when we archived most of the PV Driver related activity, which has been mostly completed. The new focus are '''mixed-criticality systems''' with the capability of being able to safety certify Xen.<br />
{{Trailbox|FuSa SIG|FuSa_SIG<br />
|{{Trail|Key pages|<br />
* [http://xenproject.org/developers/teams/embedded-and-automotive.html Project Portal]<br />
* [[FuSa SIG/Charter|Charter]]<br />
* [[FuSa SIG/Meetings|Meetings]]<br />
* [[FiSa SIG/Presentations|Presentations]]<br />
}}|{{Trail|Work Streams|<br />
* [[FuSa SIG/Work Stream/Safety Management System|Safety Management System]]<br />
* [[FuSa SIG/Work Stream/Documentation|Documentation]]<br />
* [[FuSa SIG/Work Stream/Verification Tests|Verification Tests]]<br />
* [[FuSa SIG/Work Stream/Community Interactions and Processes|Community Interactions and Processes]]<br />
* [[FuSa SIG/Work Stream/Process Automation Tools|Process Automation Tools]]<br />
}}|{{Trail|Resources|<br />
* [https://lists.xenproject.org/cgi-bin/mailman/listinfo/fusa-sig fusa-sig@ mailing list ]<br />
}}<br />
}}<br />
<br />
== New Pages ==<br />
Name new pages<br />
<pre>FuSa SIG/<topic></pre><br />
Use at the bottom of new pages for this category<br />
<pre>[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</pre><br />
Importing google docs content:<br />
* Step 1: Copy google docs text into [https://html-cleaner.com/ html-cleaner.com] <br />
* Step 2: Select the following options, then convert and copy the content into the clipboard: remove inline styles, remove classes and IDs, remove span tags, remove comments, encode special characters)<br />
* Step 3: Use [https://foliovision.com/seo-tools/pandoc-online# foliovision.com/seo-tools/pandoc-online] and convert from HTML to Mediawiki</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Meetings&diff=19951FuSa SIG/Meetings2022-03-15T01:40:57Z<p>StefanoStabellini: </p>
<hr />
<div>The Xen FuSa SIG meets bi-weekly. Please join the mailing list to request the latest information about the meeting details:<br />
<br />
https://lists.xenproject.org/mailman/listinfo/fusa-sig<br />
<br />
[[Category:Safety Certification/FuSa SIG]]<br />
[[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=FuSa_SIG/Charter&diff=19950FuSa SIG/Charter2022-03-15T01:38:25Z<p>StefanoStabellini: </p>
<hr />
<div>= Background =<br />
<br />
Modern safety critical systems such as autonomous vehicles or industrial robots are constantly and rapidly increasing their complexity with cloud-connected and dynamically deployed functions. Keeping such systems “safe” may require reducing their complexity by separating critical and non-critical parts which can be achieved with Xen.<br />
<br />
= Goal =<br />
<br />
Xen can be safety-certified: it has been certified in the past by individual companies, and experts groups have confirmed its certifiability after careful analysts of the codebase and contribution processes. However, the burden of the certification process falls on the user. The goal of the Xen FuSa SIG is to reduce this burden by moving upstream Xen closer to safety-certifiability. The Xen FuSa SIG oversees activities such as improving the Xen code quality and producing artifacts (documentation, tests, traceability matrices, etc.) necessary for certifications.<br />
<br />
= Members =<br />
<br />
* ARM (Antonio Priore, Bertrand Marquis, Robin Randhawa)<br />
* Citrix (George Dunlap)<br />
* EPAM (Artem Mygaiev, Alex Agizim)<br />
* LF (Kate Stewart)<br />
* Renesas (Hisao Munakata)<br />
* Resiltech (Francesco Rossi)<br />
* Xilinx (Stefano Stabellini)<br />
<br />
Assessors<br />
<br />
* Exida (Piotr Serwa)<br />
* MIRA (David Ward)<br />
* TUV Rheinland (Robert Heinen)<br />
* TUV SUD (Bernhard Nalte, Claudio Gregorio)<br />
<br />
= Scope =<br />
<br />
SIG activities can be represented in several streams:<br />
<br />
=== Code Quality ===<br />
<br />
Improve Xen code quality and safety. Implement features to improve real-time and reduce interference. Improve Xen coding style and align it with MISRA-C.<br />
<br />
''Keywords: MISRA, code quality, static analysis, real-time''<br />
<br />
=== Documentation ===<br />
<br />
Define and implement guidelines, templates and examples related to requirements, architecture, design and API documentation. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.<br />
<br />
''Keywords: documentation,'' ''requirements, architecture, design, APIs,'' ''traceability''<br />
<br />
=== Verification Tests ===<br />
<br />
Define and implement guidelines and examples related to the verification of requirements, architecture, design and APIs as required for safety certification. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.<br />
<br />
''Keywords: traceability, testing, dynamic analysis''<br />
<br />
<br />
[[Category:Safety Certification/FuSa SIG]] [[Category:Safety Certification]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Outreach_Program_Projects&diff=19807Outreach Program Projects2021-02-17T23:49:01Z<p>StefanoStabellini: /* Xen Hypervisor */</p>
<hr />
<div><br />
__TOC__<br />
<br />
The Xen Project is a Linux Foundation collaborative project that develops the <br />
* Xen Hypervisor (for x86 and ARM) - the bulk of this page. IRC channel #xendevel<br />
* Unikraft (see [[#Unikraft]]). IRC channel #unikraft<br />
* Mirage OS (see [[#Mirage_OS]]). IRC channel #mirage<br />
* We also have some infrastructure, tooling and community related projects that run across '''all''' the sub-projects. These are slightly different from other projects, in terms of skills: see [[#Infra_and_Community]]<br />
The project also has excellent relationships with its upstreams (Linux Kernel, the BSDs, QEMU and other projects) and upstreams such as Linux distributions. This is reflected in the project list, which contains many interesting cross-project development projects for applicants.<br />
<br />
=== Finding a project that fits you ===<br />
This page lists Xen Project development projects for Google Summer of Code and Outreachy (formerly the Outreach Program for Women). But projects can be picked up by anyone! If you're interesting in hacking Xen Project code and want to become a part of our friendly developer community this is the place to start! Ready for the challenge?<br />
<br />
'''To work on a project:'''<br />
* Send an email to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] (see '''Developer Mailing Lists''') and let us know if you are interested in starting to work or applying on a specific project.<br />
* Post your ideas, questions, RFCs to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] sooner than later so you can get comments and feedback. <br />
* An easy way to get started (and show that you can set up the Xen Development Environment, fix an issue, build and test Xen, submit a patch, etc.) is to address a suitable number of [https://www.xenproject.org/help/contribution-guidelines.html#coverity Coverity Scan issues]. <br />
* '''Small Contribution Requirement''': Outreachy requires that youfulfil the [https://wiki.gnome.org/Outreachy#Make_a_Small_Contribution Make a Small Code Contribution Requirement]. This is not strictly necessary for GSoC, but a small contribution to the project during the application period gives you an advantage<br />
<br />
'''You have your own project idea: no problem!'''<br />
* If you have your own project idea, outline what you are trying to do on the mailing list. If you know the right list, post your project idea on [http://www.xenproject.org/help/mailing-list.html mailing list]. Failing that post on xen-devel and we can redirect you to the right list. Make sure you add '''Outreachy <round>''' or '''GSoC <year>''' to the subject line.<br />
<br />
'''It is a good idea to ...'''<br><br />
The Xen Project has participated in Outreachy and Google Summer of Code (GSoC) in the past. One of the things we learned by participating in these programs is that you will be more successful, happier and get more out of participating in internship programs, if you do a bit of prep-work before writing an application. Here is some stuff you can do:<br />
* Contact your mentor early and get to know him or her<br />
* Start hanging out on our IRC channels (#xendevel, #unikraft, #mirage)<br />
* You may want to ask the mentor for a couple of small bitesize work-items (such as reviewing someones patch, a bitesize bug, ...) and start communicating on the relevant [http://www.xenproject.org/help/mailing-list.html mailing list]. That helps you become familiar with our development process, the mentor and other community members and will help you chose the right project and help you decide whether the Xen project is for you.<br />
* Note that quite a few Xen maintainers used to be GSoC participants once. Feel free to ask community dot manager at xenproject dot org to put you in touch with them if you have questions about their experience.<br />
* Any work you submit before applying for a project should be based on xen-unstable development tree, if the project is Xen Hypervisor and/or tools related. Linux kernel related patches should be based on upstream kernel.org Linux git tree (latest version). Mirage OS patches should be based on the right codeline too. Check out the '''navigation by audience''' section on the left to find resources.<br />
<br />
==== More resources ====<br />
Quick links to changelogs of the various Xen related repositories/trees: Please see [[XenRepositories]] wiki page!<br />
<br />
Before to submit patches, please look at [[Submitting Xen Patches]] wiki page and the relevant [http://www.xenproject.org/developers/teams.html Xen Project team page]. This will contain more information.<br />
<br />
If you have new ideas, suggestions or development plans let us know and we'll update this list!<br />
<br />
=== Aspiring Participants ===<br />
* Please contact the mentor and CC the most appropriate mailing list<br />
* Get a bite-size task from the mentor before the application starts<br />
* If you feel comfortable with an idea, please put your name to an idea using the following format<br />
<pre><br />
{{project<br />
...<br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} I am interested in this idea ... <br />
(note that you may also want to link to the e-mail thread with the mentor)<br />
</pre><br />
* You will need to request write access to the wiki by filling out [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html this form]<br />
<br />
<!--<br />
=== Applying for GSoC ===<br />
{{InfoLeft|Note that we will update this section when more student information on [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 melange] is available, to make it easier for you to find information. And of course assuming that the Xen Project will be accepted into GSoC.}}<br />
<br />
To apply for a project, follow the steps outlined on<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 melange]<br />
* We do have our own [[GSoC Student Application Template]] form<br />
--><br />
<br />
=== Outreach Program Project Ideas ===<br />
<!--<br />
=== GSoC Projects that were accepted in 2014 ===<br />
--><br />
<br />
<br />
== List of peer reviewed Projects ==<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
{{project<br />
|Project=golang consumer for the `xenlight` golang package<br />
|Date=28/01/2020<br />
|Verified=28/01/2020<br />
|Contact=George Dunlap <george.dunlap@citrix.com>, IRC nick: gwd <br />
|List=Make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate#<br />
|IRC=#xendevel<br />
|Difficulty=Straightforward<br />
|Skills=Familiarity with the Go language<br />
|Desc=The `xenlight` golang package consists of golang bindings for libxl, a robust library designed to be able to drive all necessary interaction with a Xen system; it's the library on which both xl and libvirt-xen are written.<br />
<br />
The golang bindings are nearing completion, and so this project would be to create an in-tree consumer of those bindings; partly as an example, partly to be useful. Ideas include:<br />
<br />
* A simple `host status` daemon which would present information about the host: memory available, domains running, and so on<br />
* A 'system stress tester', which would perform random operations (create / destroy / migrate / suspend VMs, create / destroy / migrate cpupools, &c) in quick succession to test the robustness of the system<br />
* A re-implementation of the 'xl' command in Golang, suitable to be used as a drop-in replacement in our test system<br />
* A 'wrapper' library to make creation of guests simple and straightforward, with a minimum of boilerplate<br />
<br />
Applicants are encouraged to come up with their own ideas as well.<br />
<br />
|Outcomes=A useful project or library which exercises and demonstrates how to use the `xenlight` golang package.<br />
|GSoC=yes<br />
}}<br />
<br />
<br><br />
<br />
=== Xen Toolstack ===<br />
<br />
<br><br />
<br />
=== Xen Hypervisor ===<br />
<br />
{{project<br />
|Project=Xen on ARM: Performance Counters Virtualization<br />
|Date=01/02/2019<br />
|Verified=01/28/2020<br />
|Difficulty=Hard<br />
|Contact=Stefano Stabellini <sstabellini@kernel.org>, IRC nick: sstabellini; Julien Grall <julien@xen.org>, IRC nick: julieng<br />
|List=Make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate<br />
|IRC=#xendevel<br />
|Skills=Good C, assembly, and kernel programming skills<br />
|GSoC=Yes<br />
|Desc=Performance counters are a family of ARM registers used to measure performance. Today they are not virtualized by Xen, they are just trapped and implemented as read-as-zero/write-ignore, see xen/arch/arm/arm64/vsysreg.c and xen/arch/arm/arm64/vsysreg.c. <br />
<br />
This project is about properly virtualizing these registers, so that guests can use them to measure their own performance. It involves saving and restoring the performance counters registers in Xen during VM context switch.<br />
<br />
|Outcomes=Xen guests can use performance counters.<br />
}}<br />
<br />
<br><br />
<br />
=== Unikraft ===<br />
'''Verified: 15/02/2021'''<br />
<br />
Unikraft is a unikernel build system that enables developers to build<br />
light-weight services starting from a highly customizable library base.<br />
(for more information see [http://unikraft.org here]).<br />
<br />
We keep an up-to-date list of Unikraft-related projects as issues on github [https://github.com/unikraft/unikraft/issues?q=is%3Aissue+is%3Aopen+label%3Akind%2Fproject+-label%3Alifecycle%2Factive here]. If you're interested in one of them, or have project suggestions, please write us at <simon.kuenzer@neclab.eu> and <felipe.huici@neclab.eu>, cc minios-devel@lists.xenproject.org.<br />
<br />
<br><br />
<br />
=== Mirage OS ===<br />
<br />
==== Several different projects (follow link) ====<br />
<br />
For Mirage OS, please check out the [http://canopy.mirage.io/tags/help%20needed list of Mirage OS projects where help is needed]. If you are interested in one of these projects, please e-mail [http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel mirageos-devel@lists.xenproject.org] and CC the mentor from the page (the project will contain a link to the mentor's GitHub account, which normally contains an email address and IRC information). You can also ask questions on the #mirage [http://xenproject.org/help/irc.html IRC] channel and usually find mentors on there.<br />
<br />
<br><br />
=== XAPI ===<br />
<br />
No projects at this stage.<br />
<br />
<br><br />
<br />
=== Infra and Community ===<br />
<br />
We also have some infrastructure, tooling and community related projects that run across all the sub-projects. These are slightly different from other projects, in terms of skills and working with the community. Please check extra information below the project.<br />
<br />
<br />
{{project<br />
|Project=Add Centos Virt SIG Xen packages test to the CentOS CI loop<br />
|Date=18/02/2016<br />
|Verified=16/01/2019<br />
|Difficulty=Easy<br />
|Contact=George Dunlap <george.dunlap@citrix.com>, IRC nick: gwd <br />
|List=Make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate<br />
|IRC=#xendevel<br />
|Skills=Basic shell scripting<br />
|GSoC=Yes<br />
|Desc=The CentOS project has a continuous integration (CI) system running Jenkins, which can automatically run a set of tests when specific conditions are met, such as new versions of packages being available on the CentOS community build system (CBS). The CentOS Virtualization SIG ('Special Interest Group') produces Xen packages for CentOS 6 and 7, along with other related packages (such as libvirt). The goal of this project would be to add tests to this system to test the basic functionality of the Xen packages produced by the CentOS Virt SIG, helping to avoid regressions in released software.<br />
|Outcomes=An appropriate array of tests for xen (and ideally libvirt) packages running in the CentOS CI loop.<br />
}}<br />
<br />
<!--<br />
{{project<br />
|Project=Add more FreeBSD testing to osstest<br />
|Date=10/02/2017<br />
|Verified=28/01/2019<br />
|Difficulty=Moderate<br />
|Contact=Roger Pau Monné <roger.pau@citrix.com>, IRC nick: royger; Ian Jackson <ian.jackson@eu.citrix.com>, IRC nick: Diziet<br />
|List=Make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate<br />
|IRC=#xendevel<br />
|Skills=perl and shell (to write tests for osstest), FreeBSD system administration: pxe install, complete setup, build from sources, generate installer media.<br />
|GSoC=Yes<br />
|Desc=The current Xen Project test system only has minimal support for FreeBSD: it's able to test a FreeBSD guest, but it's only able to partially setup a FreeBSD host or perform a Xen compilation on FreeBSD. This project aims to solve this by providing better integration of FreeBSD into the Xen test system (osstest).<br />
<br />
First tasks will involve writing support for building the 3rd-party packages needed for the Xen build using poudriere and creating a custom pkg repository. Next steps will involve building FreeBSD guest images from source and integrating with the xen-unstable flight.<br />
<br />
Initial support for FreeBSD host has been merged into osstest, but it's incomplete.<br />
|Outcomes=Be able to setup a FreeBSD host from osstest tracking upstream FreeBSD sources and perform a Xen build on it. Also generate FreeBSD guest images and integrate them into osstest testing.<br />
}}<br />
--><br />
<br />
<br><br />
<br />
== New Project Ideas ==<br />
{{Anchor|New_Project_Ideas}}<br />
'''Please add new project ideas here, following '''<br />
<br />
== Conventions for Projects and Project Mentors == <br />
=== Rules and Advice for Adding Ideas ===<br />
* Be creative<br />
* Add projects into [[#New_Project_Ideas|New Project Ideas]] or improve projects in [[#Unreviewed Project Ideas|Project Ideas that Need Review or more work]] through review comments.<br />
* Use the {{tl|GSoC Project}} template to encode ideas on this page. Please read the [[Template:GSoC Project|Template Documentation]] before you do so.<br />
* Be specific: what do you want to be implemented; if at all possible provide an indication of size and complexity as described above to make it easier for an applicant to choose ideas<br />
<!--<br />
* Check that the project meets the [[#Goals|GSoC Program Goals]]<br />
--><br />
* If you are willing to mentors those ideas, add your name and email to the idea.<br />
* Aspiring mentors should introduce themselves on the most appropriate Xen Project mailing list<br />
<br />
=== Peer Review Goals ===<br />
We strongly recommend and invite project proposers and project mentors to review each others proposals. When you review, please look out for<br />
* Can an intern get going and started with the information in the project description<br />
* Are any unstated assumptions in the proposal, is there undefined terminology, etc. in the proposal <br />
* Can the project completed in 3 months (assume that one month is needed for preparation)<br />
* {{Anchor|Goals}}Does the project meet Google Summer of Code goals, which are<br />
** Create and release open source code for the benefit of all<br />
** Inspire young developers to begin participating in open source development<br />
** Help open source projects identify and bring in new developers and committers <br />
** Provide interns the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")<br />
** Give interns more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)<br />
<br />
=== Peer Review Conventions ===<br />
The {{tl|GSoC Project}} template used to encode project listings, contains some review functionality. Please read the [[Template:GSoC Project|Template Documentation]] before you add a template, also please use the conventions below to make comments.<br />
<br />
<pre><br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} Comment 1<br />
* {{Comment|~~~~:}} Comment 2<br />
</pre><br />
<br />
=== Choosing Projects ===<br />
We have a bi-weekly mentor meeting overlooked by our program management team, which are a core team of 2-3 mentors and a program administrator. This group will work with mentors to ensure that project proposals are of good quality and whether mentors are engaging with the program management team and particpants in the weeks before the application period ends. <br />
<br />
== Projects completed in 2017 ==<br />
<br />
{{ProjectComplete<br />
|Project=Fuzzing Xen hypercall interface<br />
|Acknowledgement=This project was completed by '''Felix Schmoll'''<br />
|Refs=For more information see <br />
* [https://blog.xenproject.org/2017/08/25/my-gsoc-experience-fuzzing-the-hypervisor/ My GSoC experience: Fuzzing the hypervisor]<br />
* [https://lists.xen.org/archives/html/xen-devel/2017-08/msg01960.html Technical Summary of project]<br />
* [https://summerofcode.withgoogle.com/archive/2017/projects/6343132106981376/ GSoC 2017]<br />
|Date=8/02/2017<br />
|Verified=8/2/2017<br />
|Difficulty=Very high<br />
|Contact=Wei Liu <wei.liu2@citrix.com>; make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate<br />
|Skills=Strong C and ASM skills, good knowledge of GCC toolchain, good knowledge of GNU Make, good knowledge of fuzzing in general, good kernel programming and user space programming skills<br />
|GSoC=Yes (accepted in 2017 - see https://summerofcode.withgoogle.com/dashboard/project/5585891117498368/overview/)<br />
|Desc=The Xen Project has been using American Fuzzy Lop (AFL) for fuzzing and achieve useful results. Up until now we've only been able to adapt some Xen components to be fuzzed in a userspace program. There is untapped potential in using AFL (or other fuzzers) to fuzz hypercall interface. AFL (and other coverage guided fuzzers) requires feedback from the fuzzing target to mutate test cases. Xen does not yet have the ability to return precise execution path. <br />
<br />
* Create a small domain or program to accept command from fuzzer, execute test case etc.<br />
* Use GCC coverage support to give back precise execution path.<br />
* Massage and feed the input back to fuzzer.<br />
<br />
<br />
'''Related open source technologies and repositories''':<br />
* [http://lcamtuf.coredump.cx/afl/ AFL home page] (and [http://lcamtuf.coredump.cx/afl/README.txt README])<br />
* [http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf Shows how conceptually similar problems have been solved elsewhere]<br />
<br />
<br />
|Outcomes=A system for fuzzing Xen hypercall interface.<br />
}}<br />
<br />
{{ProjectComplete<br />
|Project=Share a page in memory from the VM config file<br />
|Acknowledgement=This project was completed by '''Zhongze Liu'''<br />
|Refs=For more information see <br />
* [https://blog.xenproject.org/2017/08/29/my-gsoc-experience-allow-setting-up-shared-memory-regions-between-vms-from-xl-config-file/ My GSoC Experience: Allow Setting up Shared Memory Regions between VMs from xl Config File]<br />
* [https://summerofcode.withgoogle.com/archive/2017/projects/5356246735519744/ GSoC 2017]<br />
|Date=28/02/2017<br />
|Verified=28/2/2017<br />
|Difficulty=Average<br />
|Contact=Stefano Stabellini <sstabellini@kernel.org>; Julien Grall <julien.grall@arm.com>; make sure you CC xen-devel@lists.xenproject.org on all communications; tag mails with [GSoC] or [Outreachy] as appropriate<br />
|Skills=Good C and kernel programming skills<br />
|GSoC=Yes (2017)<br />
|Desc=<br />
<br />
Virtual machines use grant table hypercalls to setup a share page for inter-VMs communications. These hypercalls are used by all PV protocols today. However, very simple guests, such as baremetal applications, might not have the infrastructure to handle the grant table. This project is about setting up a shared page for inter-VMs communications directly from the VM config file. So that the guest kernel doesn't have to have grant table support to be able to communicate with other guests.<br />
<br />
* introduce a new VM config option in xl<br />
* allocate a page in memory and add it to the VM stage2 pagetable at a given address<br />
* the page should be shareable with other virtual machines<br />
<br />
|Outcomes=A new VM config file option is introduced to share a page in memory across multiple guests<br />
}}<br />
<br />
[[Category:Developers]]<br />
[[Category:Index]]<br />
[[Category:Project]]<br />
[[Category:Internships]]<br />
[[Category:Outreachy]]<br />
[[Category:GSoC]]<br />
[[Category:Transient]] <!-- as if not maintained it becomes stale --></div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19795Xen ARM with Virtualization Extensions2020-10-13T17:42:04Z<p>StefanoStabellini: </p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|boards like: [https://www.pine64.org/rockpro64 RockPro64]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling Xen ===<br />
<br />
Cross compiling the Xen hypervisor is simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
<br />
=== Building the Toolstack ===<br />
<br />
For a complete cross-compilation of the hypervisor and the toolstack, it is recommended to use Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
Alternatively, it is possible to use qemu user to run an ARM64 chroot on a x86 host, i.e. an ARM64 Debian or Ubuntu container on a regular x86 laptop.<br />
<br />
$ apt-get install qemu-user-static<br />
<br />
It installs <tt>/usr/bin/qemu-aarch64-static</tt>.<br />
<br />
Next setup an ARM64 chroot environment on your x86 machine. Follow your distro recommandations. For instance, the following distros offer pre-packaged tarballs ready to be unpackged:<br />
<br />
* Ubuntu: http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-arm64.tar.gz<br />
* Alpine Linux: http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-minirootfs-3.11.6-aarch64.tar.gz<br />
<br />
<br />
Assuming that the ARM64 chroot is under <tt>/chroot/distro_arm64</tt>, then you can:<br />
<br />
$ cp /usr/bin/qemu-aarch64-static /chroot/distro_arm64/usr/bin/qemu-aarch64-static<br />
$ chroot /chroot/distro_arm64<br />
<br />
Now you have a full ARM64 environment running on a regular x86 machine. You can automate all the last steps with the following Docker command (the example is running Debian):<br />
<br />
$ docker run -it -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/debian /bin/bash<br />
<br />
Inside your ARM64 environment you can follow the regular native compilation steps:<br />
<br />
$ cd xen.git<br />
# install build dependencies with apt-get/apk/yum etc.<br />
$ ./configure<br />
$ make -j4<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
<br />
== Debugging ==<br />
<br />
A small set of [[Xen_ARM_DEBUG_hypercalls|DEBUG hypercalls]] are available to help debugging early boot domU issues.<br />
<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_DEBUG_hypercalls&diff=19794Xen ARM DEBUG hypercalls2020-10-13T17:40:20Z<p>StefanoStabellini: Created page with "If you are trying to DEBUG early boot code in your guest kernel, either Dom0 or DomU, you might find the Xen on ARM DEBUG hypercalls useful. They are only available to DEBUG b..."</p>
<hr />
<div>If you are trying to DEBUG early boot code in your guest kernel, either Dom0 or DomU, you might find the Xen on ARM DEBUG hypercalls useful. They are only available to DEBUG builds, i.e. builds with '''Debugging Options ---> Developer Checks''' enabled.<br />
<br />
Simply add one of the following '''hvc''' instructions to your code, and Xen will print something on the console for you:<br />
<br />
hvc 0xfffd<br />
prints the program counter<br />
<br />
hvc 0xfffe<br />
prints first byte of register x0<br />
<br />
hvc 0xffff<br />
prints all registers and stack of the guest<br />
<br />
hvc 0xffe0-0xffef<br />
prints program counter and a register: e0 prints x0, e1 prints x1, etc.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19726Xen ARM with Virtualization Extensions2020-05-20T17:16:03Z<p>StefanoStabellini: /* Building the Toolstack */</p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling Xen ===<br />
<br />
Cross compiling the Xen hypervisor is simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
<br />
=== Building the Toolstack ===<br />
<br />
For a complete cross-compilation of the hypervisor and the toolstack, it is recommended to use Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
Alternatively, it is possible to use qemu user to run an ARM64 chroot on a x86 host, i.e. an ARM64 Debian or Ubuntu container on a regular x86 laptop.<br />
<br />
$ apt-get install qemu-user-static<br />
<br />
It installs <tt>/usr/bin/qemu-aarch64-static</tt>.<br />
<br />
Next setup an ARM64 chroot environment on your x86 machine. Follow your distro recommandations. For instance, the following distros offer pre-packaged tarballs ready to be unpackged:<br />
<br />
* Ubuntu: http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-arm64.tar.gz<br />
* Alpine Linux: http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-minirootfs-3.11.6-aarch64.tar.gz<br />
<br />
<br />
Assuming that the ARM64 chroot is under <tt>/chroot/distro_arm64</tt>, then you can:<br />
<br />
$ cp /usr/bin/qemu-aarch64-static /chroot/distro_arm64/usr/bin/qemu-aarch64-static<br />
$ chroot /chroot/distro_arm64<br />
<br />
Now you have a full ARM64 environment running on a regular x86 machine. You can automate all the last steps with the following Docker command (the example is running Debian):<br />
<br />
$ docker run -it -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/debian /bin/bash<br />
<br />
Inside your ARM64 environment you can follow the regular native compilation steps:<br />
<br />
$ cd xen.git<br />
# install build dependencies with apt-get/apk/yum etc.<br />
$ ./configure<br />
$ make -j4<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19725Xen ARM with Virtualization Extensions2020-05-20T17:15:39Z<p>StefanoStabellini: /* Building the Toolstack */</p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling Xen ===<br />
<br />
Cross compiling the Xen hypervisor is simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
<br />
=== Building the Toolstack ===<br />
<br />
For a complete cross-compilation of the hypervisor and the toolstack, it is recommended to use Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
Alternatively, it is possible to use qemu user to run an ARM64 chroot on a x86 host, i.e. an ARM64 Debian or Ubuntu container on a regular x86 laptop.<br />
<br />
$ apt-get install qemu-user-static<br />
<br />
It installs <tt>/usr/bin/qemu-aarch64-static</tt>.<br />
<br />
Next setup an ARM64 chroot environment on your x86 machine. Follow your distro recommandations. For instance, the following distros offer pre-packaged tarballs ready to be unpackged:<br />
<br />
* Ubuntu: http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-arm64.tar.gz<br />
* Alpine Linux: http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-minirootfs-3.11.6-aarch64.tar.gz<br />
<br />
<br />
Assuming that the ARM64 chroot is under <tt>/chroot/distro_arm64</tt>, then you can:<br />
<br />
$ cp /usr/bin/qemu-aarch64-static /chroot/distro_arm64/usr/bin/qemu-aarch64-static<br />
$ chroot /chroot/distro_arm64<br />
<br />
Now you have a full ARM64 environment running on a regular x86 machine. You can automate all the last steps with the following Docker command (the example is running Debian):<br />
<br />
$ docker run -it -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/debian /bin/bash<br />
<br />
Inside your ARM64 environment you can follow the regular native compilation steps:<br />
<br />
$ cd xen.git<br />
# install build dependencies<br />
$ ./configure<br />
$ make -j4<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions/CrossCompiling&diff=19724Xen ARM with Virtualization Extensions/CrossCompiling2020-05-20T17:04:56Z<p>StefanoStabellini: </p>
<hr />
<div>{{WarningLeft|This page is outdated. Please refer to [[Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM]]}}<br />
<br />
= Introduction =<br />
<br />
When working with low power or constrained environments (and in particular when using software emulated platforms such as the [[Xen_ARM_with_Virtualization_Extensions/FastModels|Fast Models]]) it may not be desirable (or even possible) to build software, such as the Xen userspace tools, on the target device itself. In such cases it is necessary to build on some other more powerful/capable/suitable device. If a more powerful system of the same architecture is available then this can be achieved by simply building on that device and transferring the result to the target device. However if a more powerful system of the same architecture is not available then the software must be "cross-compiled", that is built on a system of a different host architecture using tools which produce binaries that will run on the target architecture. In the most common case this will involve using an x86 host machine to build binaries for an ARM system.<br />
<br />
There are three main ways to set up a cross compile environment:<br />
<br />
; Yocto and meta-virtualization<br />
: See [[Xen_on_ARM_and_Yocto|this page]] to use Yocto to cross-compile a minimal dom0 initramfs, including all the Xen userspace tools.<br />
; Construct a traditional cross compilation environment<br />
: This technique involves installing a compiler on the host system which runs natively on the host but produces binaries for the target system and making available all the of the libraries required for the target architecture in order to build the software in question. This is what is normally meant when people talk about cross compiling. Making all of the necessary libraries available is sometimes easier said than done however and many project's build systems do not cope well with cross-compilation (the Xen tools are cross compile friendly though).<br />
; Using a foreign chroot<br />
: This technique involves creating a chroot on the host containing a distro for the target system and using the "native" tools and libraries within this chroot to build for the target using the native build processes. This relies on the [http://wiki.qemu.org/Main_Page Qemu system emulator] to emulate a userspace environment for the target system (which is much more efficient than doing full system emulation of the target since it uses the host system's native kernel). This method is not normally as fast as traditional cross compilation but it is significantly faster than building using full system emulation and is often faster than building natively on a low powered device. This basics of this are described in a blog post [http://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/ Foreign Chroots with schroot and qemu] while a more specific example covering arm64 using openSUSE is described in [http://community.arm.com/groups/processors/blog/2014/03/28/virtualization-on-arm-with-xen Virtualization on ARM with Xen].<br />
<br />
== Target Environment ==<br />
<br />
Yocto automatically sets up the cross-compilation environment for you. If you don't use Yocto, it is important that the build (i.e. cross or foreign chroot) environment matches the runtime (i.e. dom0) environment where the tools will run. This means that the library and compiler versions etc should match. These instructions use the [http://www.ubuntu.com Ubuntu] [https://wiki.ubuntu.com/SaucySalamander Saucy Salamander] release and so that is what you would need in your dom0 as well. See [[Xen_ARM_with_Virtualization_Extensions/RootFilesystem]] for instructions on creating a root filesystem.<br />
<br />
== Xen Version ==<br />
<br />
Xen on ARM is cross buildable on an x86 host from Xen 4.4 onwards.<br />
<br />
== Typographical Conventions ==<br />
<br />
; #<br />
: Commands to run as root on the host<br />
; $<br />
: Commands to run as your regular user on the host<br />
; (chroot)#<br />
: Commands to run as root within the chroot<br />
; (chroot)$<br />
: Commands to run as the regular user in the chroot<br />
; $USER<br />
: Your regular username on the host (which is propagated to the chroot)<br />
<br />
= Using ''sbuild'' and ''schroot'' =<br />
<br />
These instructions use the [http://packages.debian.org/source/wheezy/sbuild sbuild] and [http://packages.debian.org/source/wheezy/schroot schroot] tools, which are part of Debian and Ubuntu, in order to provide a convenient mechanism for creating chroots.<br />
<br />
These instructions were tested with sbuild version 0.63.2-1.1 and schroot version 1.6.4-4 on a Debian Wheezy system.<br />
<br />
sbuild can be installed as follows, which will also pull in schroot as a dependency:<br />
<br />
# apt-get install sbuild<br />
# sbuild-adduser $USER<br />
<br />
This installs the ''sbuild'' tool and configures your existing user to be able to use it. You may need to logout and log back in for this to take affect.<br />
<br />
== If sbuild and schroot are not available ==<br />
<br />
If your host distribution does not supply ''sbuild'' then it is still possible to use a chroot in a more manual fashion. This is mostly out of scope for this document but some hints:<br />
<br />
* ''sbuild'' will automatically bind mount things inside the chroot, so if running without you will need to ensure that your source trees etc are available within the chroot, either by bind mounting manually or by copying the source tree into the chroot.<br />
<br />
* ''sbuild'' will automatically propagate any necessary host level configuration to the chroot, which you may need to do by hand. e.g. you would likely need to copy <tt>/etc/resolv.conf</tt> into the chroot in order to access the network while within the chroot.<br />
<br />
* ''sbuild'' will automatically make your $USER available inside the chroot. Either run as root within the chroot (not really recommended) or ensure that your $USER exists within the chroot with the same uid and gid.<br />
<br />
= Cross-compile chroot environment using multiarch =<br />
<br />
This section describes how to use traditional cross compilation to build the Xen tools for [[Xen ARM with Virtualization Extensions|Xen on ARM]] using the [http://wiki.debian.org/Multiarch Multiarch] infrastructure available in Debian and Ubuntu to create a cross build chroot environment using (and targeting) Ubuntu Saucy Salamander.<br />
<br />
In principal it might be possible to use multiarch on the host to setup a cross environment without using a chroot, however multiarch does not currently support both native and cross compilation at the same time so it is easier to put the cross environment into a chroot.<br />
<br />
== Creating a base chroot ==<br />
<br />
In order to setup a crossbuild chroot we first need a base chroot. Note that the 32 bit arm architecture in Debian and Ubuntu is called ''armhf''. If you are intending to build for 64-bit substitute '''arm64''' for '''armhf''' everywhere in the following.<br />
<br />
Create the initial base chroot. This will be a native host (i.e. x86) chroot into which we will install an ARM cross compile environment:<br />
<br />
# sbuild-createchroot --components=main,universe saucy /srv/chroots/saucy-armhf-cross http://archive.ubuntu.com/ubuntu/<br />
<br />
This creates /etc/schroot/chroot.d/saucy-amd64-sbuild-* (with a random suffix) and a chroot named saucy-amd64-sbuild using the ''sbuild'' profile. The profile should be changed to ''default''. Also the naming is confusing if you create multiple cross build chroots. So rename the file and edit the configuration file as shown:<br />
<br />
# mv /etc/schroot/chroot.d/saucy-amd64-sbuild-* /etc/schroot/chroot.d/saucy-armhf-cross<br />
# vi /etc/schroot/chroot.d/saucy-armhf-cross<br />
''[saucy-amd64-sbuild]'' | '''[saucy-armhf-cross]'''<br />
type=directory | type=directory<br />
''description=Debian saucy/amd64 autobuilder'' | '''description=Debian saucy/armhf crossbuilder'''<br />
directory=/srv/chroots/saucy-armhf-cross | directory=/srv/chroots/saucy-armhf-cross<br />
groups=root,sbuild | groups=root,sbuild<br />
root-groups=root,sbuild | root-groups=root,sbuild<br />
''profile=sbuild'' | '''profile=default'''<br />
<br />
You now have a base chroot named ''saucy-armhf-cross'' or ''saucy-arm64-cross''.<br />
<br />
== 32-bit crossbuild ==<br />
<br />
=== Configuring an armhf crossbuild chroot ===<br />
<br />
After creating a base ''saucy-armhf-cross'' chroot as described above we then configure it to add the multiarch cross capabilities. Enter the chroot as root with:<br />
<br />
# schroot -c saucy-armhf-cross<br />
<br />
Install some basic utilities:<br />
<br />
(chroot)# apt-get install vim-tiny wget sudo less pkgbinarymangler<br />
<br />
Configure the package sources, qualifying the main repositories as ''amd64'' only and adding the ''armhf'' repositories from the ports archive:<br />
<br />
(chroot)# vi /etc/apt/sources.list<br />
deb '''[arch=amd64]''' http://archive.ubuntu.com/ubuntu/ saucy main universe<br />
deb-src '''[arch=amd64]''' http://archive.ubuntu.com/ubuntu/ saucy main universe<br />
<br />
'''deb [arch=armhf] http://ports.ubuntu.com/ saucy main universe'''<br />
<br />
Since this is a cross-build chroot Recommended and Suggested packages are largely unnecessary, create ''/etc/apt/apt.conf.d/30norecommends'' containing:<br />
<br />
APT::Install-Recommends "0";<br />
APT::Install-Suggests "0";<br />
<br />
Now add ''armhf'' as an additional architecture and install the basic crossbuild infrastructure:<br />
<br />
(chroot)# dpkg --add-architecture armhf<br />
(chroot)# apt-get update<br />
(chroot)# apt-get install crossbuild-essential-armhf<br />
<br />
Next install the build dependencies required to build Xen:<br />
(chroot)# apt-get install libc6-dev:armhf libncurses-dev:armhf uuid-dev:armhf libglib2.0-dev:armhf libssl-dev:armhf libssl-dev:armhf libaio-dev:armhf libyajl-dev:armhf python gettext gcc git libpython2.7-dev:armhf libfdt-dev:armhf<br />
<br />
We have now finished configuring the chroot, so exit:<br />
(chroot)# exit<br />
<br />
=== Build arm32 tools ===<br />
<br />
Enter your 32-bit crossbuild chroot as your regular user:<br />
<br />
$ schroot -c saucy-armhf-cross<br />
<br />
Change to the directory where you have cloned Xen and cross compile with:<br />
<br />
(chroot)$ CONFIG_SITE=/etc/dpkg-cross/cross-config.armhf ./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabihf<br />
(chroot)$ make dist-tools CROSS_COMPILE=arm-linux-gnueabihf- XEN_TARGET_ARCH=arm32<br />
<br />
That's all there is to it. You should now have a ''dist/install'' directory containing the installed bits which can be copied into your arm32 rootfs.<br />
<br />
== 64-bit crossbuild ==<br />
<br />
=== Introduction ===<br />
<br />
These instructions have been massively simplified with the release of Saucy Salamander vs the previous Raring Ringtail release. They are essentially identical to the armhf variant.<br />
<br />
=== Configuring an arm64 crossbuild chroot ===<br />
<br />
After creating a base ''saucy-arm64-cross'' chroot as described above we then configure it to add the multiarch cross capabilities. Enter the chroot as root with:<br />
<br />
# schroot -c saucy-arm64-cross<br />
<br />
Install some basic utilities:<br />
<br />
(chroot)# apt-get install vim-tiny wget sudo less pkgbinarymangler<br />
<br />
Configure the package sources, qualifying the main repositories as ''amd64'' only and adding the ''arm64'' repositories from the ports archive:<br />
<br />
(chroot)# vi /etc/apt/sources.list<br />
deb '''[arch=amd64]''' http://archive.ubuntu.com/ubuntu/ saucy main universe<br />
deb-src '''[arch=amd64]''' http://archive.ubuntu.com/ubuntu/ saucy main universe<br />
<br />
'''deb [arch=arm64] http://ports.ubuntu.com/ saucy main universe'''<br />
<br />
Since this is a cross-build chroot Recommended and Suggested packages are largely unnecessary, create ''/etc/apt/apt.conf.d/30norecommends'' containing:<br />
<br />
APT::Install-Recommends "0";<br />
APT::Install-Suggests "0";<br />
<br />
Now add ''arm64'' as an additional architecture and install the basic crossbuild infrastructure:<br />
<br />
(chroot)# dpkg --add-architecture arm64<br />
(chroot)# apt-get update<br />
(chroot)# apt-get install crossbuild-essential-arm64<br />
<br />
Next install the build dependencies required to build Xen:<br />
(chroot)# apt-get install libc6-dev:arm64 libncurses-dev:arm64 uuid-dev:arm64 libglib2.0-dev:arm64 libssl-dev:arm64 libssl-dev:arm64 libaio-dev:arm64 libyajl-dev:arm64 python gettext gcc git libpython2.7-dev:arm64 libfdt-dev:arm64<br />
<br />
We also need the ''autotools-dev'' package to workaround out of date autoconf machinery in the Xen 4.4.0 release:<br />
(chroot)# apt-get install autotools-dev<br />
<br />
We have now finished configuring the chroot, so exit:<br />
(chroot)# exit<br />
<br />
=== Build arm64 tools ===<br />
<br />
Enter your 64-bit crossbuild chroot as your regular user:<br />
<br />
$ schroot -c saucy-arm64-cross<br />
<br />
Change to the directory where you have cloned Xen and cross compile.<br />
<br />
If building Xen 4.4.0 then it is first necessary to update the autoconf machinery with versions which know about arm64:<br />
<br />
(chroot)$ cp /usr/share/misc/config.{sub,guess} .<br />
<br />
Now we can cross compile:<br />
<br />
(chroot)$ CONFIG_SITE=/etc/dpkg-cross/cross-config.arm64 ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-gnu<br />
(chroot)$ make dist-tools CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64<br />
<br />
You should now have a ''dist/install'' directory containing the installed bits which can be copied into your arm64 rootfs.<br />
<br />
== References ==<br />
<br />
The procedure here is based somewhat loosely on https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap plus Wookey's kind advice at Linaro Connect.<br />
<br />
[[Category:XenARM]] [[Category:Developers]] [[Category:Yocto]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19723Xen ARM with Virtualization Extensions2020-05-20T17:02:40Z<p>StefanoStabellini: /* Building Xen on ARM */</p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling Xen ===<br />
<br />
Cross compiling the Xen hypervisor is simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
<br />
=== Building the Toolstack ===<br />
<br />
For a complete cross-compilation of the hypervisor and the toolstack, it is recommended to use Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
Alternatively, it is possible to use qemu user to run an ARM64 chroot on a x86 host, i.e. an ARM64 Debian or Ubuntu container on a regular x86 laptop.<br />
<br />
$ apt-get install qemu-user-static<br />
<br />
It installs <tt>/usr/bin/qemu-aarch64-static</tt>.<br />
<br />
Next setup an ARM64 chroot environment on your x86 machine. Follow your distro recommandations. For instance, the following distros offer pre-packaged tarballs ready to be unpackged:<br />
<br />
* Ubuntu: http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-arm64.tar.gz<br />
* Alpine Linux: http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-minirootfs-3.11.6-aarch64.tar.gz<br />
<br />
<br />
Assuming that the ARM64 chroot is under <tt>/chroot/distro_arm64</tt>, then you can:<br />
<br />
$ cp /usr/bin/qemu-aarch64-static /chroot/distro_arm64/usr/bin/qemu-aarch64-static<br />
$ chroot /chroot/distro_arm64<br />
<br />
Now you have a full ARM64 environment running on a regular x86 machine. You can automate all the last steps with the following Docker command (the example is running Debian):<br />
<br />
$ docker run -it -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/debian /bin/bash<br />
<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19722Xen ARM with Virtualization Extensions2020-05-20T17:01:52Z<p>StefanoStabellini: /* Building Xen on ARM */</p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling Xen ===<br />
<br />
Cross compiling the Xen hypervisor is simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
<br />
=== Building the Toolstack ===<br />
<br />
For a complete cross-compilation of the hypervisor and the toolstack, it is recommended to use Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
Alternatively, it is possible to use qemu user to run an ARM64 chroot on a x86 host, i.e. an ARM64 Debian or Ubuntu container on a regular x86 laptop.<br />
<br />
$ apt-get install qemu-user-static<br />
<br />
It installs <tt>/usr/bin/qemu-aarch64-static<tt>.<br />
<br />
Next setup an ARM64 chroot environment on your x86 machine. Follow your distro recommandations. For instance, the following distros offer pre-packaged tarballs ready to be unpackged:<br />
<br />
* Ubuntu: http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04-base-arm64.tar.gz<br />
* Alpine Linux: http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-minirootfs-3.11.6-aarch64.tar.gz<br />
<br />
<br />
Assuming that the ARM64 chroot is under <tt>/chroot/distro_arm64<tt>, then you can:<br />
<br />
$ cp /usr/bin/qemu-aarch64-static /chroot/distro_arm64/usr/bin/qemu-aarch64-static<br />
$ chroot /chroot/distro_arm64<br />
<br />
Now you have a full ARM64 environment running on a regular x86 machine. You can automate all the last steps with the following Docker command (the example is running Debian):<br />
<br />
$ docker run -it -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/debian /bin/bash<br />
<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19658Xen on ARM and Yocto2019-11-09T02:08:24Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev"<br />
ASSUME_PROVIDED += "iasl-native"<br />
PACKAGECONFIG_remove_pn-xen += " sdl"<br />
<br />
Sdl is enabled by default in the Xen build but it is not actually necessary.<br />
If you would like to build QEMU to provide PV backends, such as disk and 9pfs, then you need to add to conf/local.conf:<br />
<br />
IMAGE_INSTALL_append += " qemu"<br />
PACKAGECONFIG_pn-qemu += " virtfs xen fdt"<br />
PACKAGECONFIG_remove_pn-qemu += " sdl"<br />
QEMU_TARGETS = "i386 aarch64"<br />
<br />
Note that we only care about the i386 QEMU target because that is the one that comes with the Xen PV backends, but the aarch64 target is required to make the build succeed.<br />
If you are using meta-xilinx and building for ''zcu102-zynqmp'', then you also need the following in conf/local.conf:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and the following to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19657Xen on ARM and Yocto2019-11-09T02:01:25Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev"<br />
ASSUME_PROVIDED += "iasl-native"<br />
PACKAGECONFIG_remove_pn-xen += " sdl"<br />
<br />
Sdl is enabled by default in the Xen build but it is not actually necessary.<br />
If you would like to build QEMU to provide PV backends, such as disk and 9pfs, then you need to add to conf/local.conf:<br />
<br />
IMAGE_INSTALL_append += " qemu"<br />
PACKAGECONFIG_pn-qemu += " virtfs xen fdt"<br />
PACKAGECONFIG_remove_pn-qemu += " sdl"<br />
QEMU_TARGETS = "i386 aarch64"<br />
<br />
If you are using meta-xilinx and building for ''zcu102-zynqmp'', then you also need the following in conf/local.conf:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and the following to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19656Xen on ARM and Yocto2019-11-09T01:59:46Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev"<br />
ASSUME_PROVIDED += "iasl-native"<br />
PACKAGECONFIG_remove_pn-xen += " sdl"<br />
<br />
Sdl is enabled by default in the Xen build but it is not actually necessary.<br />
If you would like to build QEMU to provide PV backends, such as disk and 9pfs, then you need to add to conf/local.conf:<br />
<br />
IMAGE_INSTALL_append += " qemu"<br />
PACKAGECONFIG_pn-qemu += " virtfs xen fdt"<br />
PACKAGECONFIG_remove_pn-qemu += " sdl"<br />
QEMU_TARGETS = "i386 aarch64"<br />
<br />
If you are using meta-xilinx and building for ''zcu102-zynqmp'', then you also need the following in conf/local.conf:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and the following to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=ImageBuilder&diff=19651ImageBuilder2019-10-30T17:20:04Z<p>StefanoStabellini: /* uboot-script-gen */</p>
<hr />
<div>= Booting Xen from U-Boot =<br />
<br />
Booting Xen from U-Boot requires:<br />
<br />
* loading all the required binaries, manually specifying the loading address for each of them making sure they don't overlap<br />
** Xen, Dom0 kernel, Dom0 ramdisk, device tree binary, any Dom0-less DomUs kernels, ramdisk and partial dtbs for passthrough<br />
<br />
* adding relevant nodes to device tree<br />
** the Dom0 kernel and ramdisk loading addresses need to be specified in device tree under /chosen<br />
<br />
See [https://xenbits.xenproject.org/docs/unstable/misc/arm/device-tree/booting.txt booting.txt] as a reference.<br />
<br />
= ImageBuilder =<br />
<br />
The whole process can be automated with '''ImageBuilder''':<br />
<br />
[https://gitlab.com/ViryaOS/imagebuilder https://gitlab.com/ViryaOS/imagebuilder]<br />
<br />
ImageBuilder can be invoked as a container for build automation, but its useful scripts can also be called manually. Specifically, '''script/uboot-script-gen''' generates a U-Boot script that loads all the necessary binaries and automatically adds the required entries to device tree at boot time. In order to use it, you need to write a config file first.<br />
<br />
== Config file ==<br />
<br />
<nowiki><br />
MEMORY_START="0x0"<br />
MEMORY_END="0x80000000"<br />
<br />
DEVICE_TREE="board.dtb"<br />
XEN="xen-hypervisor"<br />
DOM0_KERNEL="Image-dom0"<br />
DOM0_RAMDISK="ramdisk-dom0.rootfs.cpio.gz"<br />
<br />
NUM_DOMUS=2<br />
DOMU_KERNEL[0]="dom1/Image-domU"<br />
DOMU_RAMDISK[0]="dom1/ramdisk-domU"<br />
DOMU_PASSTHROUGH_DTB[0]="dom1/passthrough-domU.dtb"<br />
DOMU_KERNEL[1]="dom2/Image-domU"<br />
DOMU_RAMDISK[1]="dom2/ramdisk-domU2"<br />
<br />
UBOOT_SOURCE="boot.source"<br />
UBOOT_SCRIPT="boot.scr"<br />
</nowiki><br />
<br />
The fields are self explanatory but you can find more detailed information on the [https://gitlab.com/ViryaOS/imagebuilder/blob/master/README.md readme]. Make sure to use raw binaries for Xen, all the kernels and rootfs's, not U-Boot binaries (do '''not''' use the output of mkimage).<br />
<br />
== uboot-script-gen ==<br />
<br />
Once you have the config file, you can call uboot-script-gen as follows:<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t tftp<br />
</nowiki><br />
<br />
uboot-script-gen generates a U-Boot script named '''boot.scr''' that will load all your binaries automatically using tftp.<br />
<br />
All the path specified in the config file are relative to the directory passed as an argument to -d. In this case, ''Image-dom0'' and ''dom1/Image-domU'' must be relative to the current directory, because we are passing -d . to uboot-script-gen.<br />
<br />
Now, you just need to load the generated boot.scr and source it from U-Boot:<br />
<br />
<nowiki><br />
u-boot> tftpb 0xC00000 boot.scr; source 0xC00000<br />
</nowiki><br />
<br />
The command used to load the binaries can be customized, for instance you can have uboot-script-gen generate a U-Boot script that loads binaries from a SD card passing -t sd, which is a syntactic sugar for -t "load scsi 0:1":<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t sd<br />
</nowiki><br />
<br />
= Important Notes =<br />
<br />
== Xen and Dom0 command line ==<br />
ImageBuilder uses sched=null by default. If you want to change it, and also modify other Xen and/or Dom0 command line options you'll make to edit the generated U-Boot script: '''boot.source'''. Look for sched=null in the source and edit as needed. Then you need to regenerate '''boot.scr''' using mkimage and specifying the same loading address for the boot.scr as printed earlier by uboot-script-gen:<br />
<br />
<nowiki><br />
$ mkimage -A arm64 -T script -C none -a 0xC00000 -e 0xC00000 -d boot.source boot.scr<br />
</nowiki><br />
<br />
== U-Boot binaries vs. raw binaries ==<br />
<br />
uboot-script-gen takes only raw binaries as input. If you have a U-Boot binary in your hands and you want to convert it back to a raw binary, you can do that with the following command:<br />
<br />
<nowiki><br />
$ dd if=uboot-binary-source of=raw-binary-dest bs=64 skip=1<br />
</nowiki><br />
<br />
== Xen booting as raw binary ==<br />
<br />
If you use a version of Xen older than 4.12, you need to make sure to have the following commit backported in your Xen tree:<br />
<br />
<nowiki><br />
4f3d0ed5d9 xen:arm: Populate arm64 image header<br />
</nowiki><br />
<br />
It is necessary to be able to boot Xen as a raw binary from U-Boot.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=ImageBuilder&diff=19650ImageBuilder2019-10-24T18:03:08Z<p>StefanoStabellini: </p>
<hr />
<div>= Booting Xen from U-Boot =<br />
<br />
Booting Xen from U-Boot requires:<br />
<br />
* loading all the required binaries, manually specifying the loading address for each of them making sure they don't overlap<br />
** Xen, Dom0 kernel, Dom0 ramdisk, device tree binary, any Dom0-less DomUs kernels, ramdisk and partial dtbs for passthrough<br />
<br />
* adding relevant nodes to device tree<br />
** the Dom0 kernel and ramdisk loading addresses need to be specified in device tree under /chosen<br />
<br />
See [https://xenbits.xenproject.org/docs/unstable/misc/arm/device-tree/booting.txt booting.txt] as a reference.<br />
<br />
= ImageBuilder =<br />
<br />
The whole process can be automated with '''ImageBuilder''':<br />
<br />
[https://gitlab.com/ViryaOS/imagebuilder https://gitlab.com/ViryaOS/imagebuilder]<br />
<br />
ImageBuilder can be invoked as a container for build automation, but its useful scripts can also be called manually. Specifically, '''script/uboot-script-gen''' generates a U-Boot script that loads all the necessary binaries and automatically adds the required entries to device tree at boot time. In order to use it, you need to write a config file first.<br />
<br />
== Config file ==<br />
<br />
<nowiki><br />
MEMORY_START="0x0"<br />
MEMORY_END="0x80000000"<br />
<br />
DEVICE_TREE="board.dtb"<br />
XEN="xen-hypervisor"<br />
DOM0_KERNEL="Image-dom0"<br />
DOM0_RAMDISK="ramdisk-dom0.rootfs.cpio.gz"<br />
<br />
NUM_DOMUS=2<br />
DOMU_KERNEL[0]="dom1/Image-domU"<br />
DOMU_RAMDISK[0]="dom1/ramdisk-domU"<br />
DOMU_PASSTHROUGH_DTB[0]="dom1/passthrough-domU.dtb"<br />
DOMU_KERNEL[1]="dom2/Image-domU"<br />
DOMU_RAMDISK[1]="dom2/ramdisk-domU2"<br />
<br />
UBOOT_SOURCE="boot.source"<br />
UBOOT_SCRIPT="boot.scr"<br />
</nowiki><br />
<br />
The fields are self explanatory but you can find more detailed information on the [https://gitlab.com/ViryaOS/imagebuilder/blob/master/README.md readme]. Make sure to use raw binaries for Xen, all the kernels and rootfs's, not U-Boot binaries (do '''not''' use the output of mkimage).<br />
<br />
== uboot-script-gen ==<br />
<br />
Once you have the config file, you can call uboot-script-gen as follows:<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t tftp<br />
</nowiki><br />
<br />
uboot-script-gen generates a U-Boot script named '''boot.scr''' that will load all your binaries automatically using tftp.<br />
<br />
All the path specified in the config file are relative to the directory passed as an argument to -d. In this case, ''Image-dom0'' and ''dom1/Image-domU'' must be relative to the current directory, because we are passing -d . to uboot-script-gen.<br />
<br />
Now, you just need to load the generated boot.scr and source it from U-Boot:<br />
<br />
<nowiki><br />
$ tftpb 0xC00000 boot.scr; source 0xC00000<br />
</nowiki><br />
<br />
The command used to load the binaries can be customized, for instance you can have uboot-script-gen generate a U-Boot script that loads binaries from a SD card passing -t sd, which is a syntactic sugar for -t "load scsi 0:1":<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t sd<br />
</nowiki><br />
<br />
= Important Notes =<br />
<br />
== Xen and Dom0 command line ==<br />
ImageBuilder uses sched=null by default. If you want to change it, and also modify other Xen and/or Dom0 command line options you'll make to edit the generated U-Boot script: '''boot.source'''. Look for sched=null in the source and edit as needed. Then you need to regenerate '''boot.scr''' using mkimage and specifying the same loading address for the boot.scr as printed earlier by uboot-script-gen:<br />
<br />
<nowiki><br />
$ mkimage -A arm64 -T script -C none -a 0xC00000 -e 0xC00000 -d boot.source boot.scr<br />
</nowiki><br />
<br />
== U-Boot binaries vs. raw binaries ==<br />
<br />
uboot-script-gen takes only raw binaries as input. If you have a U-Boot binary in your hands and you want to convert it back to a raw binary, you can do that with the following command:<br />
<br />
<nowiki><br />
$ dd if=uboot-binary-source of=raw-binary-dest bs=64 skip=1<br />
</nowiki><br />
<br />
== Xen booting as raw binary ==<br />
<br />
If you use a version of Xen older than 4.12, you need to make sure to have the following commit backported in your Xen tree:<br />
<br />
<nowiki><br />
4f3d0ed5d9 xen:arm: Populate arm64 image header<br />
</nowiki><br />
<br />
It is necessary to be able to boot Xen as a raw binary from U-Boot.</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19649Xen on ARM and Yocto2019-10-24T17:35:15Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
If you are using meta-xilinx and building for ''zcu102-zynqmp'', then you also need to add the following to conf/local.conf:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and the following to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19648Xen on ARM and Yocto2019-10-24T17:34:16Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
You also need to add the following if you are using meta-xilinx:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and also add to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19647Xen on ARM and Yocto2019-10-24T17:33:47Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
You also need to add the following if you are using meta-xilinx:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and also add to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19646Xen on ARM and Yocto2019-10-24T17:33:37Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
$ git clone -b warrior http://git.yoctoproject.org/git/poky<br />
$ cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
You also need to add the following if you are using meta-xilinx:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and also add to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19645Xen on ARM and Yocto2019-10-24T17:33:22Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
git clone -b warrior http://git.yoctoproject.org/git/poky<br />
cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
You also need to add the following if you are using meta-xilinx:<br />
<br />
BBMULTICONFIG ?= "pmu"<br />
do_image[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"<br />
<br />
and also add to conf/multiconfig/pmu.conf:<br />
<br />
MACHINE="zynqmp-pmu" <br />
DISTRO="xilinx-standalone" <br />
TMPDIR="${TOPDIR}/pmutmp"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_on_ARM_and_Yocto&diff=19644Xen on ARM and Yocto2019-10-24T17:29:21Z<p>StefanoStabellini: </p>
<hr />
<div>Follow these instructions to cross-compile a minimal Dom0 initramfs, with all the Xen tools, for ARM64 platforms. The build runs on x86 machines, while the target is ARM64. In this example, we are targeting Xilinx Zynq MPSoCs.<br />
<br />
Firstly clone the poky, we are using the ''warrior'' release:<br />
<br />
git clone -b warrior http://git.yoctoproject.org/git/poky<br />
cd poky<br />
<br />
Download and install the relevant meta repositories:<br />
<br />
$ git clone -b warrior http://git.openembedded.org/meta-openembedded<br />
$ git clone http://github.com/cazfi/meta-games.git<br />
$ git clone -b warrior https://git.yoctoproject.org/git/meta-virtualization<br />
<br />
The following is specific to Xilinx:<br />
<br />
git clone -b warrior https://github.com/Xilinx/meta-xilinx.git<br />
<br />
meta-games is needed for sdl but freeciv causes issues with warrior. Let's remove it:<br />
<br />
$ rm -rf meta-games/recipes-games/freeciv/<br />
<br />
Manually edit conf/bblayers.conf, add the following, where /scratch/repos/poky is the directory where you cloned poky previously:<br />
BBLAYERS ?= " \<br />
/scratch/repos/poky/meta \<br />
/scratch/repos/poky/meta-poky \<br />
/scratch/repos/poky/meta-yocto-bsp \<br />
/scratch/repos/poky/meta-openembedded/meta-oe \<br />
/scratch/repos/poky/meta-openembedded/meta-filesystems \<br />
/scratch/repos/poky/meta-openembedded/meta-python \<br />
/scratch/repos/poky/meta-openembedded/meta-networking \<br />
/scratch/repos/poky/meta-games \<br />
/scratch/repos/poky/meta-virtualization \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-bsp \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-contrib \<br />
/scratch/repos/poky/meta-xilinx/meta-xilinx-standalone \<br />
"<br />
INHERIT += "externalsrc"<br />
EXTERNALSRC_pn-xen = "/scratch/repos/xen"<br />
EXTERNALSRC_BUILD_pn-xen = "/scratch/repos/xen"<br />
<br />
Edit conf/local.conf, add the following or making sure they match if already present (MACHINE is the target platform, here we are using ''zcu102-zynqmp'' as reference):<br />
<br />
MACHINE ??= "zcu102-zynqmp"<br />
DISTRO = "poky"<br />
IMAGE_FSTYPES += "cpio.gz"<br />
DISTRO_FEATURES_append=" xen"<br />
IMAGE_INSTALL_append = " busybox dropbear xen-base zlib-dev libsdl-net libsdl-mixer"<br />
ASSUME_PROVIDED += "iasl-native"<br />
<br />
IMAGE_INSTALL_append = " dropbear" <br />
INITRAMFS_IMAGE = "core-image-minimal"<br />
INITRAMFS_IMAGE_BUNDLE = "1"<br />
<br />
<br />
Finally lunch the build!<br />
<br />
bitbake core-image-minimal<br />
<br />
The output will be under build/tmp/deploy/images.<br />
<br />
<br />
[[Category:XenARM]] [[Category:Yocto]] [[Category:Developers]] [[Category:OpenEmbedded]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions&diff=19643Xen ARM with Virtualization Extensions2019-10-24T17:21:28Z<p>StefanoStabellini: /* Building Xen on ARM */</p>
<hr />
<div>{{Hatnote|For the ARM port supporting paravirtualized guests on processors without the virtualization extensions see [[Xen ARM (PV)]].}}<br />
<br />
The ARM v7-A and ARM v8-A architectures include optional virtualization extensions that allow a hypervisor to manage fully hardware virtualized guests. These extensions are currently available in some ARM v7 processors such as the Cortex A15 and Cortex A7.<br />
<br />
== Introduction ==<br />
If you are interested in the Xen on ARM architecture and how it compares to Xen on x86, read the [[Xen_ARM_with_Virtualization_Extensions_whitepaper| Xen on ARM whitepaper]].<br />
<br />
== Status ==<br />
<br />
Both the 32-bit (arm32) and the 64-bit (arm64) ports of Xen boot dom0 and unprivileged guests can be created and destroyed using ''xl''. See below for information on the hardware and models. You may also want to read [[Xen ARM with Virtualization Extensions whitepaper|our whitepaper]] that explains the basic architecture and terminology of Xen on ARM.<br />
<br />
=== Guest ABI ===<br />
<br />
The guest (including dom0) visible [http://xenbits.xen.org/docs/unstable/hypercall/arm/index.html ABI exposed by the hypervisor] has been declared stable as of the 4.4 release and will now be maintained in a backwards compatible manner.<br />
<br />
== Contributing ==<br />
<br />
Please email [mailto:xen-devel@lists.xen.org xen-devel] with comments, questions and patches. Please see the [http://lists.xen.org/xen-devel list info page] for subscription information and the [http://lists.xen.org/archives/html/xen-devel/ archives]. For patches please see [[Submitting Xen Patches]].<br />
<br />
== Testing ==<br />
There are a lot of different ARM boards and servers with many different IP blocks available. The project's CI loop can only test a small subset of these, as we cannot afford to buy and test against all possible boards. As such, we will be relying on manual testing during [[Xen Project Test Days]] to verify which ARM hardware works and which doesn't. The good news, is that from experience the vast majority of board specific issues will occur during boot and thus a a simple [[Xen ARM Manual Smoke Test]] is usually sufficient to identify such issues.<br />
<br />
The [[Xen ARM Manual Smoke Test/Results]] contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table. By doing so you will help others and yourself.<br />
<br />
== Hardware ==<br />
<br />
{|class="prettytable" style="text-align: left;" valign="top"<br />
!Core/SoC/Board<br />
!Xen Guide<br />
!Notes<br />
|-<br />
!colspan="3"|ARM Cortex [http://www.arm.com/products/processors/cortex-a/cortex-a7.php A7]/[http://www.arm.com/products/processors/cortex-a/cortex-a15.php A15]<br />
|-<br />
|ARM Cortex A7/A15 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model] (FVP)<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|[http://www.arm.com/products/tools/development-boards/versatile-express/ Versatile Express]<br />
|[[Xen ARM with Virtualization Extensions/Vexpress|Versatile Express]]<br />
|With TC2 daughterboard<br />
|-<br />
|Calxeda EXC-2000<br />
|[[Xen ARM with Virtualization Extensions/Midway|Midway]]<br />
|<br />
|-<br />
|colspan="3"|'''[http://www.allwinnertech.com/ Allwinner] sunxi'''<br />
|-<br />
|&nbsp;[http://www.allwinnertech.com/en/clq/processora/A20.html sun7i/A20]<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|[http://linux-sunxi.org/A20 linux-sunxi community]. e.g. [http://linux-sunxi.org/Cubietech_Cubietruck Cubietruck]<br />
|-<br />
|&nbsp;sun6i/A31<br />
|<br />
|[http://linux-sunxi.org/A31 linux-sunxi community]<br />
|-<br />
|colspan="3"|'''Exynos5xxx'''<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 Exynos5250]<br />
|[[Xen ARM with Virtualization Extensions/Arndale|Arndale]]<br />
|[http://www.arndaleboard.org/wiki/index.php/Main_Page www.arndaleboard.org]<br />
|-<br />
|&nbsp;[http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7976&iaId=2341 Exynos5410]<br />
|[[Xen ARM with Virtualization Extensions/OdroidXU|OdroidXU]]<br />
|[http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620 www.hardkernel.com]<br />
|-<br />
|colspan="3"|'''OMAP5'''<br />
|-<br />
|&nbsp;[http://www.ti.com/product/omap5432 OMAP5432]<br />
|[[Xen ARM with Virtualization Extensions/OMAP5432_uEVM|uEVM]]<br />
|[http://www.ti.com/tool/omap5432-evm www.ti.com]<br />
|-<br />
|colspan="3"|'''Renesas R-Car H2/H3'''<br />
|-<br />
|[http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Lager|Lager]]<br />
|-<br />
|[https://elinux.org/R-Car/Boards/Stout Renesas R-Car H2]<br />
|[[Xen ARM with Virtualization Extensions/Stout|Stout]]<br />
|-<br />
|[https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html Renesas R-Car H3]<br />
|[[Xen ARM with Virtualization Extensions/Salvator-X|Salvator-X]]<br />
|-<br />
!colspan="3"|ARM Cortex [http://arm.com/products/processors/cortex-a/cortex-a53-processor.php A53]/[http://arm.com/products/processors/cortex-a/cortex-a57-processor.php A57]<br />
|-<br />
|[https://www.qemu.org/ QEMU AArch64 Emulator]<br />
|[[Xen ARM with Virtualization Extensions/qemu-system-aarch64|QEMU]]<br />
|Fast Open Source emulator<br />
|-<br />
|[http://www.arm.com/products/tools/models/fast-models/foundation-model.php ARMv8 Foundation Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Free as in beer emulator<br />
|-<br />
|ARM AEMv8 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
|ARM Cortex A53/A57 [http://www.arm.com/products/tools/models/fast-models/index.php Real-time System Model]<br />
|[[Xen ARM with Virtualization Extensions/FastModels|Fastmodels]]<br />
|Commercial emulator<br />
|-<br />
![https://www.apm.com/products/data-center/x-gene-family/ Applied Micro X-Gene]<br />
||[https://www.apm.com/products/data-center/x-gene-family/x-gene/ X-Gene]<br />
|[[Xen ARM with Virtualization Extensions/APMXGeneMustang|Mustang]] (XC-1), HP Moonshot (McDivitt)<br />
|<br />
|-<br />
![https://www.96boards.org/products/ce/hikey HiKey board from 96boards.org]<br />
|[[HiKey|HiKey]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.96boards.org/product/hikey960/ HiKey960 board from 96boards.org]<br />
|[[HiKey960|HiKey960]]<br />
|Open Hardware Platform<br />
|-<br />
![http://www.xilinx.com/products/technology/ultrascale-mpsoc.html Xilinx Zynq UltraScale+ MPSoC (ZynqMP)]<br />
||[http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx Wiki]<br />
|Open Source Emulator [http://www.wiki.xilinx.com/QEMU+-+Zynq+UltraScalePlus QEMU for ZynqMP]<br />
|-<br />
![http://wiki.espressobin.net/tiki-index.php ESPRESSObin based on Marvell ARMADA 3700]<br />
|[[Xen ARM with Virtualization Extensions/ESPRESSObin|ESPRESSObin]]<br />
|Hardware Platform<br />
|-<br />
![http://linux-sunxi.org/A64 Allwinner A64]/[http://linux-sunxi.org/H5 H5] based boards<br />
|[[Xen ARM with Virtualization Extensions/Allwinner|Allwinner]]<br />
|boards like: [http://linux-sunxi.org/Pine64 Pine64], [http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2 OrangePi PC 2]<br />
|-<br />
!colspan="3"|ARM Cortex [https://developer.arm.com/products/processors/cortex-a/cortex-a53 A53]/[https://developer.arm.com/products/processors/cortex-a/cortex-a72 A72]<br />
|-<br />
![http://www.9tripod.com/showpro.php?id=93 Ibox3399 board based on Rockchip RK3399]<br />
|[[Xen ARM with Virtualization Extensions/Ibox3399|Ibox3399]]<br />
|-<br />
<br />
|}<br />
<br />
<br />
[[Xen ARM with Virtualization Extensions/Chromebook|Early work]] was also done to support the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook Google Chromebook], however this is no longer continued since it is not a good development platform.<br />
<br />
== Requirements ==<br />
<br />
;ARM Hardware or Software Model<br />
:See above for details of the hardware and models which are supported.<br />
;Firmware<br />
:Xen requires certain functionality from the system firmware. See below for details.<br />
;Device Tree<br />
:A [[device tree]] in the flat device tree format (.dtb). The host platform must be described in a DTB binary passed to Xen at boot time. This will be used by Xen and Dom0. Normally the regular device tree used when booting natively on the platform should be used.<br />
;Xen<br />
:All current work is now merged into the current development branch [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git]. It is recommended to use the latest Xen master branch.<br />
;Linux kernel for dom0<br />
:The patches necessary to boot Linux as dom0 under Xen were merged upstream in v3.7. In order to actually start guests a few additional patches were required however these patches have now been included in the v3.8 Linux release. The latest Linus' tree has everything needed to run on Xen on ARM as dom0 and domU. It is recommended to use the latest Linux release where possible.<br />
;dom0 userspace<br />
:The developers are using the armhf port of Debian Wheezy.<br />
;domU kernel<br />
:The patches necessary to boot Linux as a guest under Xen were merged upstream in v3.7.<br />
<br />
=== Hypervisor ABI Compatibility ===<br />
<br />
The ABI for Xen on ARM was declared stable from Xen 4.4 onwards.<br />
<br />
This ABI is implemented by Linux mainline v3.9-rc1 onwards.<br />
<br />
Although not a hypervisor ABI change Linux versions prior to v3.13-rc5 (specifically [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=380108d891acf8db5cf0d477176c7ed2b62b7928 380108d891ac "xen/block: Correctly define structures in public headers on ARM32 and ARM64"]) incorrectly defined the PV block protocol on ARM. This means that versions of Linux prior to this fix are only able to interoperate (as either front or backend) with other versions of Linux prior to this commit. After this fix Linux correctly uses the same protocol as other ports (e.g. BSD).<br />
<br />
=== Firmware Requirements ===<br />
<br />
The primary requirement is that the hypervisor must be launched in Non-Secure Hypervisor mode only. If the stock firmware on a platform does not obey this (most commonly by launching in Secure Supervisor mode) then a firmware update may be required. This support is present in u-boot 2014.01.<br />
<br />
Booting secondary processors on an SMP system requires firmware support for the Power State Coordination Interfaces (PSCI). Initial u-boot support for this interface is available in https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci .<br />
<br />
When running Xen under a FastModel (which typically have no firmware at all) it is sometimes necessary to use a ''boot-wrapper''. See the [[Xen ARM with Virtualization Extensions/FastModels|Fast Model]] page for more information.<br />
<br />
Xen previously included a workaround for firmware which lacked this functionality, however it was unmaintainable and interfered with proper support for other platforms and therefore as of September 2013 it has been removed.<br />
<br />
== Booting Natively ==<br />
<br />
Before starting to load Xen it is highly recommended to get the kernel you intend to use as dom0 booting natively (i.e. without Xen underneath). This will let you iron out any driver issues and figure out the necessary kernel command line etc before adding Xen into the mix.<br />
<br />
== Booting Xen ==<br />
<br />
=== ImageBuilder ===<br />
<br />
Many of the details necessary to boot Xen from U-Boot can be generated automatically by ImageBuilder's '''uboot-script-gen''', see [[ImageBuilder]].<br />
<br />
=== Boot Protocol ===<br />
<br />
Xen's boot requirements are spelled out in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD docs/misc/arm/booting.txt] in the Xen tree, which references the Linux [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting arm] and [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt arm64] booting documentation.<br />
<br />
=== Device Trees ===<br />
<br />
Xen needs the device trees to be in the flat device tree format (the ''device tree blob'' or ''DTB'').<br />
<br />
It is no longer necessary to build a specific DTB for use with Xen. The Device Tree files shipped with [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Linux] or from the [http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git Split Device Tree Repository] can be used.<br />
<br />
=== Boot Modules ===<br />
<br />
At boot time Xen must be provided with a dom0 kernel blob and an optional dom0 initramfs blob. The bootloader must load these into memory and describe their location in the Device Tree Blob using the bindings specified in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt].<br />
<br />
These nodes can either be added by hand (by editing and recompiling the .dts file) or by using u-boot's "fdt" command to add them dynamically at boot time:<br />
<br />
fdt addr ${fdt_addr}<br />
fdt resize<br />
<br />
fdt set /chosen \#address-cells <1><br />
fdt set /chosen \#size-cells <1><br />
<br />
fdt mknod /chosen module@0<br />
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"<br />
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} ><br />
fdt set /chosen/module@0 bootargs "<DOMAIN 0 COMMAND LINE>"<br />
<br />
(this assumes the device tree blob is loaded at ${fdt_addr} and the kernel at ${kernel_addr_r}).<br />
<br />
See e.g. [[Xen_ARM_with_Virtualization_Extensions/Allwinner]] for a more concrete example of this.<br />
<br />
=== Command Lines ===<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD docs/misc/arm/device-tree/booting.txt] describes where Xen looks for both its own command line and the command line to pass to domain 0.<br />
<br />
=== Getting Xen output ===<br />
<br />
To get output log on the UART, Xen needs to know which UART to use. This should be passed in the hypervisor command line using the "dtuart" parameter. e.g.:<br />
<br />
console=dtuart dtuart=myserial<br />
<br />
where ''myserial'' is either an alias to the UART in the device tree (aliases are found in the '''aliases''' device tree node) or a full DTB path to the device. As Xen already uses it the UART will be disabled from the point of view of domain 0.<br />
<br />
For instance, this is a dummy device tree (won't work) to use the uart0 in Xen:<br />
/ {<br />
choosen {<br />
bootargs = "console=dtuart dtuart=myserial";<br />
}<br />
aliases {<br />
myserial = &myserial_0;<br />
}<br />
myserial_0: uart0 {<br />
... configuration of your UART ...<br />
}<br />
}<br />
<br />
Here dtuart is configured using the ''myserial'' alias. Alternatively ''/uart0'' (the full path to the device) could have been used.<br />
<br />
'''Note''': If you don't see output from Xen, you can enable [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/early-printk.txt;hb=HEAD early printk]. This option will turn on platform specific UART and output information before the console is initialized.<br />
<br />
== Dom0 kernel ==<br />
<br />
In general the same kernel configuration as used to boot natively, plus turning on the Xen specific options should work. A good starting point is often the "multi_v7_defconfig" + Xen options.<br />
<br />
If ARM_APPENDED_DTB is enabled then any appended DTB will be used instead of one supplied by Xen and the kernel will crash unless the memory in the DTB matches that location/size supplied by Xen. It is strongly recommended not to append a DTB to your dom0 kernel (or to disable APPENDED_DTB).<br />
<br />
== DomU kernel and DTS ==<br />
<br />
Unprivileged guests can be created using ''xl''. A simple VM config file would look like this:<br />
<br />
kernel = "/root/image"<br />
memory = 128<br />
name = "guest"<br />
vcpus = 1<br />
disk = [ 'phy:/dev/loop0,xvda,w' ]<br />
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug rw init=/bin/sh"<br />
<br />
where "/root/image" is a Linux zImage.<br />
<br />
=== Common DomU Pitfalls ===<br />
<br />
; Enabling <tt>CONFIG_DEBUG_LL</tt> in the guest kernel configuration.<br />
: Although this option can work for dom0 if configured appropriately for the host it does not work for domU (which cannot see the host UART). The symptoms of this are that the guest console will be silent because the kernel has taken a fault accessing the early UART. This can be confirmed by using the <tt>xenctx</tt> tool (found in <tt>$PREFIX/lib/xen/bin/</tt>). The tool takes a numeric domid (not a name, use <tt>xl list</tt> or <tt>xl domid $name</tt>) and dumps the VCPU state. A PC of 0x0000000c will usually indicate that an early trap has occurred.<br />
<br />
== Building Xen on ARM ==<br />
<br />
{{WarningLeft|At least gcc version 4.7.3 is known to miscompile certain parts of Xen, most often leading to a segmentation fault in the xl toolstack while starting a guest. We recommend using 4.8.x or later}}<br />
<br />
There are two major components which need to be built for a Xen system. The Xen hypervisor binary itself and the Xen toolstack.<br />
<br />
=== Cross Compiling ===<br />
<br />
Cross compiling the Xen hypervisor is relatively simple.<br />
<br />
Linaro supply cross compilers for both arm32 (arm-linux-gnueabihf-) and arm64 (aarch64-linux-gnu-) via [https://launchpad.net/linaro-toolchain-binaries linaro-toolchain-binaries]. Alternatively, for 32-bit at least, you can download the arm-unknown-linux-gnueabi compiler from [http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ kernel.org].<br />
<br />
Once you have a suitable cross compiler you can compile Xen with:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-unknown-linux-gnueabihf-<br />
<br />
or:<br />
<br />
$ make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-<br />
<br />
This assumes that the command prefix for you cross compiler is <tt>arm-unknown-linux-gnueabihf-</tt> or <tt>aarch64-linux-gnu-</tt> and that the appropriate <tt>arm-unknown-linux-gnueabihf-gcc</tt> or <tt>aarch64-linux-gnu-gcc</tt> and friends are in your $PATH.<br />
<br />
Cross compilation of the Xen toolstack is described in [[Xen ARM with Virtualization Extensions/CrossCompiling]].<br />
For full cross-build of hypervisor and toolstack together based on Yocto, see [[Xen_on_ARM_and_Yocto]].<br />
<br />
<br />
=== Native Building ===<br />
<br />
In order to build the tools a native build environment is required. For 32-bit the developers mainly use the ''armhf'' port of Debian, which is present in Wheezy running on an IMX53 based development board, although any ARMv7 development board would do. Note that the build hardware does not need to support the virtualisation extensions, since you don't have to run Xen on the same system as where you build it.<br />
<br />
It may also be possible to build using a cross-architecture chroot running on an X86 system as described in [http://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/ this blog post], although this hasn't been tried yet.<br />
<br />
== Use of qemu-system-i386 on ARM ==<br />
<br />
This surprises many people.<br />
<br />
Xen on ARM uses qemu only to provide certain PV backends (primarily qdisk and pvfb). However the Xen PV backend code on the qemu side is a bit entangled with the x86 stuff, due to the historical use with x86 HVM guests.<br />
<br />
Work on untangling things is ongoing but in the meantime qemu-system-i386 is what you want on ARM too. There is no CPU emulation in this mode so there is no danger of it trying to execute anything etc.<br />
<br />
== Open issues, known problems and workarounds ==<br />
<br />
=== <tt>error: "PSR_MODE_EL3h" redefined</tt> ===<br />
<br />
When build the tools for arm64 you may see:<br />
<br />
In file included from<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/xen.h:35:0,<br />
from /root/xenbits/xen/tools/xenstore/../../tools/libxc/include/xenctrl.h:37,<br />
from xenstored_core.h:23,<br />
from xenstored_core.c:49:<br />
/root/xenbits/xen/tools/xenstore/../../tools/include/xen/arch-arm.h:345:0: error: "PSR_MODE_EL3h" redefined [-Werror]<br />
In file included from /usr/include/sys/user.h:25:0,<br />
from /usr/include/sys/procfs.h:34,<br />
from /usr/include/sys/ucontext.h:26,<br />
from /usr/include/signal.h:360,<br />
from xenstored_core.c:40:<br />
/usr/include/asm/ptrace.h:36:0: note: this is the location of the previous definition<br />
<br />
and/or other similar <code>PSR_MODE_*</code> errors.<br />
<br />
This is a glibc bug, see [https://bugs.launchpad.net/linaro-aarch64/+bug/1169164 Linaro launchpad bug #1169164]. <br />
<br />
This has been fixed in newer glibc, so first check if your distro has a fixed version available.<br />
<br />
If not then you can either apply the patch from the bug directly to the headers under <code>/usr/include</code> (not really recommended, since future upgrades may overwrite them) or edit <code>xen/include/public/arch-arm.h</code> and insert the following before <code>#define PSR_MODE_BIT 0x10</code>:<br />
<br />
#undef PSR_MODE_BIT<br />
#undef PSR_MODE_EL3h<br />
#undef PSR_MODE_EL3t<br />
#undef PSR_MODE_EL2h<br />
#undef PSR_MODE_EL2t<br />
#undef PSR_MODE_EL1h<br />
#undef PSR_MODE_EL1t<br />
#undef PSR_MODE_EL0t<br />
<br />
=== [[Xen_ARM_TODO|TODO]] ===<br />
<br />
See [[Xen_ARM_TODO|this page]] for a full list of bugs and projects.<br />
<br />
== Also See ==<br />
* [[Automotive_Whitepapers]]<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]</div>StefanoStabellinihttps://wiki.xenproject.org/index.php?title=ImageBuilder&diff=19642ImageBuilder2019-10-23T17:36:29Z<p>StefanoStabellini: /* uboot-script-gen */</p>
<hr />
<div>= Booting Xen from U-Boot =<br />
<br />
Booting Xen from U-Boot requires:<br />
<br />
* loading all the required binaries, manually specifying the loading address for each of them making sure they don't overlap<br />
** Xen, Dom0 kernel, Dom0 ramdisk, device tree binary, any Dom0-less DomUs kernels, ramdisk and partial dtbs for passthrough<br />
<br />
* adding relevant nodes to device tree<br />
** the Dom0 kernel and ramdisk loading addresses need to be specified in device tree under /chosen<br />
<br />
See [https://xenbits.xenproject.org/docs/unstable/misc/arm/device-tree/booting.txt booting.txt] as a reference.<br />
<br />
= ImageBuilder =<br />
<br />
The whole process can be automated with '''ImageBuilder''':<br />
<br />
[https://gitlab.com/ViryaOS/imagebuilder https://gitlab.com/ViryaOS/imagebuilder]<br />
<br />
ImageBuilder can be invoked as a container for build automation, but its useful scripts can also be called manually. Specifically, '''script/uboot-script-gen''' generates a U-Boot script that loads all the necessary binaries and automatically adds the required entries to device tree at boot time. In order to use it, you need to write a config file first.<br />
<br />
== Config file ==<br />
<br />
<nowiki><br />
MEMORY_START="0x0"<br />
MEMORY_END="0x80000000"<br />
<br />
DEVICE_TREE="board.dtb"<br />
XEN="xen-hypervisor"<br />
DOM0_KERNEL="Image-dom0"<br />
DOM0_RAMDISK="ramdisk-dom0.rootfs.cpio.gz"<br />
<br />
NUM_DOMUS=2<br />
DOMU_KERNEL[0]="dom1/Image-domU"<br />
DOMU_RAMDISK[0]="dom1/ramdisk-domU"<br />
DOMU_PASSTHROUGH_DTB[0]="dom1/passthrough-domU.dtb"<br />
DOMU_KERNEL[1]="dom2/Image-domU"<br />
DOMU_RAMDISK[1]="dom2/ramdisk-domU2"<br />
<br />
UBOOT_SOURCE="boot.source"<br />
UBOOT_SCRIPT="boot.scr"<br />
</nowiki><br />
<br />
The fields are self explanatory but you can find more detailed information on the [https://gitlab.com/ViryaOS/imagebuilder/blob/master/README.md readme]. Make sure to use raw binaries for Xen, all the kernels and rootfs's, not U-Boot binaries (do '''not''' use the output of mkimage).<br />
<br />
== uboot-script-gen ==<br />
<br />
Once you have the config file, you can call uboot-script-gen as follows:<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t tftp<br />
</nowiki><br />
<br />
to generate a U-Boot script named '''boot.scr''' that will load all your binaries automatically using tftp. The paths specified in the config file are relative to the directory pass as -d. Now, you just need to load the generated boot.scr and source it from U-Boot:<br />
<br />
<nowiki><br />
$ tftpb 0xC00000 boot.scr; source 0xC00000<br />
</nowiki><br />
<br />
The command used to load the binaries can be customized, for instance you can have uboot-script-gen generate a U-Boot script that loads binaries from a SD card passing -t sd, which is a syntactic sugar for -t "load scsi 0:1":<br />
<br />
<nowiki><br />
$ bash ./scripts/uboot-script-gen -c /path/to/config -d . -t sd<br />
</nowiki><br />
<br />
= Important Notes =<br />
<br />
== Xen and Dom0 command line ==<br />
ImageBuilder uses sched=null by default. If you want to change it, and also modify other Xen and/or Dom0 command line options you'll make to edit the generated U-Boot script: '''boot.source'''. Look for sched=null in the source and edit as needed. Then you need to regenerate '''boot.scr''' using mkimage and specifying the same loading address for the boot.scr as printed earlier by uboot-script-gen:<br />
<br />
<nowiki><br />
$ mkimage -A arm64 -T script -C none -a 0xC00000 -e 0xC00000 -d boot.source boot.scr<br />
</nowiki><br />
<br />
== U-Boot binaries vs. raw binaries ==<br />
<br />
uboot-script-gen takes only raw binaries as input. If you have a U-Boot binary in your hands and you want to convert it back to a raw binary, you can do that with the following command:<br />
<br />
<nowiki><br />
$ dd if=uboot-binary-source of=raw-binary-dest bs=64 skip=1<br />
</nowiki><br />
<br />
== Xen booting as raw binary ==<br />
<br />
If you use a version of Xen older than 4.12, you need to make sure to have the following commit backported in your Xen tree:<br />
<br />
<nowiki><br />
4f3d0ed5d9 xen:arm: Populate arm64 image header<br />
</nowiki><br />
<br />
It is necessary to be able to boot Xen as a raw binary from U-Boot.</div>StefanoStabellini