Hi Ayan, > On 12 Dec 2024, at 20:03, Ayan Kumar Halder <[email protected]> wrote: > > From: Michal Orzel <[email protected]> > > Add requirements for dom0less domain creation. > > Signed-off-by: Michal Orzel <[email protected]> > Signed-off-by: Ayan Kumar Halder <[email protected]> > --- > Changes from v1 :- > > 1. As the dom0less domain creation requirements specifies the dt properties > for creating domains, it has been moved to product requirements. Product > requirements define the interface Xen exposes to other domains. > > 2. For the requirements which introduces new terms (like grant table, etc), I > have provided the definition as part of the comments. > > 3. Introduced new market requirements to specify that Xen can assign iomem and > irqs to domains. > > 4. The design requirements will be added later. > > docs/fusa/reqs/market-reqs/reqs.rst | 16 ++ > docs/fusa/reqs/product-reqs/arm64/reqs.rst | 306 +++++++++++++++++++++ > 2 files changed, 322 insertions(+) > > diff --git a/docs/fusa/reqs/market-reqs/reqs.rst > b/docs/fusa/reqs/market-reqs/reqs.rst > index f456788d96..47e1b6ad61 100644 > --- a/docs/fusa/reqs/market-reqs/reqs.rst > +++ b/docs/fusa/reqs/market-reqs/reqs.rst > @@ -47,3 +47,19 @@ Comments: > > Needs: > - XenProd > + > +Static VM definition > +-------------------- > + > +`XenMkt~static_vm_definition~1` > + > +Description: > +Xen shall support assigning peripherals to various domains. > + > +Rationale: > + > +Comments: > +Peripheral implies an iomem (input output memory) and/or interrupts. > + > +Needs: > + - XenProd > diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst > b/docs/fusa/reqs/product-reqs/arm64/reqs.rst > index db91c47a02..66f2978733 100644 > --- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst > +++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst > @@ -40,3 +40,309 @@ Covers: > > Needs: > - XenSwdgn > + > +Linux kernel image > +------------------ > + > +`XenProd~linux_kernel_image~1` > + > +Description: > +Xen shall create a domain with a Arm64 Linux kernel image [1].
This shall be rephrased to mention that it shall be a binary with a header compliant with the Linux kernel image format. We do not want to say that we can only boot Linux. > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Gzip Linux kernel image > +----------------------- > + > +`XenProd~linux_kernel_gzip_image~1` > + > +Description: > +Xen shall create a domain with a Arm64 Gzip compressed Linux kernel image. Ditto. > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Kernel with uImage header > +------------------------- > + > +`XenProd~kernel_uimage~1` > + > +Description: > +Xen shall create a domain with a kernel containing uImage header [2]. I would remove kernel and say binary executable and add compatible or something like that. > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Gzip kernel with uImage header > +------------------------------ > + > +`XenSwdgn~arm64_gzip_kernel_uimage~1` > + > +Description: > +Xen shall create a domain with a Gzip compressed kernel containing uImage > +header [2]. Same > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Kernel command line arguments > +----------------------------- > + > +`XenSwdgn~kernel_cmd_line_args~1` > + > +Description: > +Xen shall pass kernel command line arguments to a domain. I am a bit wondering if this one and the following are not a bit to generic. Should we say through DT or ACPI header for example ? > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Ramdisk > +------- > + > +`XenSwdgn~ramdisk~1` > + > +Description: > +Xen shall provide initial ramdisk to a domain. This should be mentioning that it is provided in memory and the address is provided through DT. > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Memory > +------ > + > +`XenSwdgn~memory~1` > + > +Description: > +Xen shall create a domain with specified amount of memory. I am missing the where this is specified here ? i guess this is also DT > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +vCPUs > +----- > + > +`XenSwdgn~vcpus~1` > + > +Description: > +Xen shall create a domain with a number of virtual CPUs. number here is unprecise > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Credit2 CPU pool scheduler > +-------------------------- > + > +`XenSwdgn~credit2_cpu_pool_scheduler~1` > + > +Description: > +Xen shall assign a Credit2 CPU pool scheduler [3] to a domain. What is Credit2 ? this needs to be defined somewhere and in fact it shall have product level requirements. > + > +Rationale: > + > +Comments: > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +NUL CPU pool scheduler > +---------------------- > + > +`XenSwdgn~nul_cpu_pool_scheduler~1` > + > +Description: > +Xen shall assign a NUL CPU pool scheduler to a domain. Same > + > +Rationale: > + > +Comments: > +A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu. This is a product requirement saying that Xen shall have a scheduler with such characteristics and I think this is not enough to define it. > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +SPIs > +---- > + > +`XenSwdgn~spis~1` > + > +Description: > +Xen shall allocate a specified number of shared peripheral interrupts for a > +domain. This is very ambiguous. What do you mean here ? > + > +Rationale: > + > +Comments: > +A shared peripheral interrupt is an interrupt generated by a peripheral that > is > +accessible across all the cpu cores. > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + - `XenMkt~static_vm_definition~1` > + > +Needs: > + - XenSwdgn > + > +Grant table frames > +------------------ > + > +`XenSwdgn~grant_table_frames~1` > + > +Description: > +Xen shall create a domain with a specified number of grant table frames. It is really weird to say that Xen shall create something specific without this being linked to an higher level definition of the goal. > + > +Rationale: > + > +Comments: > +Grant tables are a mechanism for sharing and transferring frames (memory > buffers) > +between domains. > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Grant maptrack frames > +--------------------- > + > +`XenSwdgn~grant_maptrack_frames~1` > + > +Description: > +Xen shall create a domain with a specified number of grant maptrack frames. Why is this needed ? what is the high level req for this ? > + > +Rationale: > + > +Comments: > +Maptrack frame is the metadata for tracking the memory mapped into a domain. > + > +Covers: > + - `XenMkt~run_arm64_domains~1` > + > +Needs: > + - XenSwdgn > + > +Virtual PL011 > +------------- > + > +`XenProd~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 > + > +Assign iomem > +------------ > + > +`XenProd~assign_iomem~1` > + > +Description: > +Xen shall support assigning iomem to a domain. > + > +Rationale: > + > +Comments: > + > +Rationale: > + > +Covers: > + - `XenMkt~static_vm_definition~1` > + > +Needs: > + - XenSwdgn > + > +Forward interrupts > +------------------ > + > +`XenProd~forward_irqs~1` > + > +Description: > +Xen shall support forwarding interrupts to a domain. > + > +Rationale: > + > +Comments: > + > +Rationale: > + > +Covers: > + - `XenMkt~static_vm_definition~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://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/features/sched_credit2.pandoc > -- > 2.25.1 >
