docs: fusa: Add dom0less domain configuration requirements

Add requirements for dom0less domain creation.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
This commit is contained in:
Michal Orzel committed 2025-01-09 17:37:58 +01:00
1 parent 4d8acc9c1c
commit b9f9b39645
4 files changed
+319 -2

No files matched your search

+1
View File
@@ -8,6 +8,7 @@ Requirements documentation
intro
market-reqs/reqs
product-reqs/reqs
product-reqs/arm64/reqs
design-reqs/arm64/generic-timer
design-reqs/arm64/sbsa-uart
+32
View File
@@ -47,3 +47,35 @@ Comments:
Needs:
- XenProd
Static VM definition
--------------------
`XenMkt~static_vm_definition~1`
Description:
Xen shall support assigning peripherals to a domain.
Rationale:
Comments:
Peripheral implies an iomem (input output memory) and/or interrupts.
Needs:
- XenProd
Multiple schedulers
-------------------
`XenMkt~multiple_schedulers~1`
Description:
Xen shall have configurable scheduling strategies of virtual cpus onto physical
cpus.
Rationale:
Comments:
Needs:
- XenProd
+126 -2
View File
@@ -6,7 +6,7 @@ Domain Creation And Runtime
Emulated Timer
--------------
`XenProd~emulated_timer~1`
`XenProd~arm64_emulated_timer~1`
Description:
Xen shall grant access to "Arm Generic Timer" for the domains.
@@ -25,7 +25,7 @@ Needs:
Emulated UART
-------------
`XenProd~emulated_uart~1`
`XenProd~arm64_emulated_uart~1`
Description:
Xen shall provide an "Arm SBSA UART" compliant device to the domains.
@@ -40,3 +40,127 @@ Covers:
Needs:
- XenSwdgn
Linux kernel image
------------------
`XenProd~arm64_linux_kernel_image~1`
Description:
Xen shall create a domain with a binary containing header compliant with Arm64
Linux kernel image [1].
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Gzip Linux kernel image
-----------------------
`XenProd~arm64_linux_kernel_gzip_image~1`
Description:
Xen shall create a domain with a Gzip compressed binary containing header
compliant with Arm64 Linux kernel image [1].
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Kernel with uImage header
-------------------------
`XenProd~arm64_kernel_uimage~1`
Description:
Xen shall create a domain with a binary containing uImage header [2].
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Gzip kernel with uImage header
------------------------------
`XenProd~arm64_gzip_kernel_uimage~1`
Description:
Xen shall create a domain with a Gzip compressed binary containing uImage
header [2].
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
SPIs
----
`XenProd~arm64_spis~1`
Description:
Xen shall assign hardware shared peripheral interrupts specified in the device
tree to a domain.
Rationale:
Comments:
Device tree is a data structure and language for describing hardware which is
readable by an operating system [3].
A shared peripheral interrupt is a peripheral interrupt that the Arm Generic
Interrupt Controller's Distributor interface can route to any combination of
processors [4].
Covers:
- `XenMkt~run_arm64_domains~1`
- `XenMkt~static_vm_definition~1`
Needs:
- XenSwdgn
Virtual PL011
-------------
`XenProd~arm64_virtual_pl011~1`
Description:
Xen shall provide an "Arm PL011 UART" compliant device to the domains.
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
- `XenMkt~provide_console_domains~1`
Needs:
- XenSwdgn
| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/booting.rst
| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h#L315
| [3] https://docs.kernel.org/devicetree/usage-model.html
| [4] https://developer.arm.com/documentation/ihi0048/a/Introduction/Terminology/Interrupt-types?lang=en
+160
View File
@@ -0,0 +1,160 @@
.. SPDX-License-Identifier: CC-BY-4.0
Domain Creation And Runtime
===========================
Kernel command line arguments
-----------------------------
`XenProd~kernel_cmd_line_args~1`
Description:
Xen shall pass kernel command line arguments to a domain via a device tree.
Rationale:
Comments:
Device tree is a data structure and language for describing hardware which is
readable by an operating system [1].
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Ramdisk
-------
`XenProd~ramdisk~1`
Description:
Xen shall provide the address of an initial ramdisk to a domain via a device
tree.
Rationale:
Comments:
The initial ramdisk is contained in memory.
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Memory
------
`XenProd~memory~1`
Description:
Xen shall create a domain with the amount of memory specified in a device tree.
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
vCPUs
-----
`XenProd~vcpus~1`
Description:
A domain shall have a configurable number of virtual CPUs (1 to 128).
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
Needs:
- XenSwdgn
Credit2 CPU pool scheduler
--------------------------
`XenProd~credit2_cpu_pool_scheduler~1`
Description:
Xen shall have a credit2 scheduler where a physical cpu can be shared between
more than one virtual cpu.
Rationale:
Comments:
Covers:
- `XenMkt~run_arm64_domains~1`
- `XenMkt~multiple_schedulers~1`
Needs:
- XenSwdgn
NUL CPU pool scheduler
----------------------
`XenProd~nul_cpu_pool_scheduler~1`
Description:
Xen shall have a nul scheduler where the domain virtual cpu is always running on
its dedicated physical cpu.
Rationale:
Comments:
A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
Covers:
- `XenMkt~run_arm64_domains~1`
- `XenMkt~multiple_schedulers~1`
Needs:
- XenSwdgn
Assign iomem
------------
`XenProd~assign_iomem~1`
Description:
Xen shall support assigning pages of iomem (address and size aligned to a page)
to a domain.
Rationale:
Comments:
Covers:
- `XenMkt~static_vm_definition~1`
Needs:
- XenSwdgn
Forward interrupts
------------------
`XenProd~forward_irqs~1`
Description:
Xen shall support forwarding hardware interrupts to a domain.
Rationale:
Comments:
Covers:
- `XenMkt~static_vm_definition~1`
Needs:
- XenSwdgn
| [1] https://docs.kernel.org/devicetree/usage-model.html
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.