Re: [PATCH] docs: fusa: Add dom0less domain configuration requirements

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

On 19/11/2024 09:04, Bertrand Marquis wrote:
> Hi Ayan and Julien,
Hi,
> > On 16 Nov 2024, at 10:57, Julien Grall <julien@xxxxxxx> wrote:
> >
> > Hi Ayan,
> >
> > On 15/11/2024 18:53, Ayan Kumar Halder wrote:
> > > > > +Assign vCPUs from CPU pool
> > > > > +--------------------------
> > > > > +
> > > > > +`XenSwdgn~arm64_assign_vcpus_cpu_pool~1`
> > > > > +
> > > > > +Description:
> > > > > +Xen shall assign vCPUs to a domain from a CPU pool.
> > > > Same remark about the wording. You create a domain with N vCPUs and *assign* a 
> > > > CPU pool to a domain.
> > > Ok, so all the previous 3 requirements can be merged into
> > > Xen shall create a domain with N vCPUs and assign a CPU pool to a domain.
> > > Or
> > > Xen shall create a domain with N vCPUs.
> > I think this one is better because it is not mandatory for the user to select a 
> > CPU pool and you will have it ...
> >
> > > (which of the two looks better to you if we keep the next requirement ?)
> > ... by the next one.
> >
> > > Comments:
> > > Here N is determined by the device tree configuration provided by the user.
> > > > You also assign pCPU to a CPU pool.
> > > >
> > > > But I am not sure about if this requirement is actually necessary given ...
> > > >
> > > > > +
> > > > > +Rationale:
> > > > > +
> > > > > +Comments:
> > > > > +
> > > > > +Covers:
> > > > > + - `XenProd~static_domains_configuration~1`
> > > > > +
> > > > > +Specify CPU pool scheduler
> > > > > +--------------------------
> > > > > +
> > > > > +`XenSwdgn~arm64_specify_cpu_pool_scheduler~1`
> > > > > +
> > > > > +Description:
> > > > > +Xen shall assign a CPU pool scheduler to a domain.
> > > > ... you have th is one.
> > > So, we can keep it as it is.
> > > > > +
> > > > > +Rationale:
> > > > > +
> > > > > +Comments:
> > > > > +
> > > > > +Covers:
> > > > > + - `XenProd~static_domains_configuration~1`
> > > > > +
> > > > > +Assign virtual UART
> > > > > +-------------------
> > > > > +
> > > > > +`XenSwdgn~arm64_assign_virtual_uart~1`
> > > > > +
> > > > > +Description:
> > > > > +Xen shall assign a virtual UART to a domain.
> > > > Are we talking about the virtual PL011 or the fake emulation of the real UART 
> > > > we do?
> > > virtual PL011.
> > Is it possible to specify it in the market requirements?
> >
> > [...]
> >
> > > > > +
> > > > > +Static VM definition
> > > > > +--------------------
> > > > > +
> > > > > +`XenMkt~static_vm_definition~1`
> > > > > +
> > > > > +Description:
> > > > > +Xen shall support specifying resources for a domain.
> > > > Compare to the other requirements, this is quite a vague. Should we list the 
> > > > resources?
> > > The list of resources depends on what the user has provided in the device tree 
> > > configuration.
> > > But the requirement is correct as it is. Xen allows direct assignment of 
> > > devices to domains (ie passthrough).
> > > How do you want to write it ?
> > This is probably a better question for Bertrand. I don't know how market 
> > requirements are usually described. I was making a comparison with the other 
> > where you explicitely listed the expected resources (e.g. CPU, Memory, device).
> I definitely agree with Julien here, this requirement is not clear as 
> "resources" is not specified or defined.
> I would highly suggest to be more specific by listing what we mean by resources 
> and maybe even split this requirement in several to make testing and linking 
> easier.
As per our discussion , the market requirement should be

Xen shall support assigning peripherals to various domains.

Comment: /* we need to define peripheral */

Peripheral implies an iomem (input output memory) and/or interrupts.

(This aligns with our definition of market requirement where we specify 
the capabilities of Xen at a high level.)
And the product requirements should be

1. Xen shall support assigning iomem to a domain.

2. Xen shall support forwarding interrupts to a domain.

(Here, we try to describe the interface between Xen and domain. So, 
domains unterstand how Xen will interact with them.)
The design requirements will be

1. Xen shall create a mapping for iomem in stage 2 page tables.

2. Xen shall route the interrupts to the domains.

3. Xen shall add iommu master (if present) for the iomem, to the 
domain's device tree.
4. Xen shall add the iomem to its iommu master.

5. Xen shall allow assignment of iomem without iommu protection.

The design requirements are still a bit high level ie it does not 
describe the details (at register level or granular level) of how Xen 
creates a mapping (for eg).
The advantage is that the requirements will be linked to the top level 
functions. It will allow the underneath functions to change without 
requiring us to modify the requirements.
Besides, it will help us to provide some justification for the missing 
coverage at the lower level (ie we can say that we don't really care if 
Xen chooses to  perform a manual translation vs hardware translation. )
- Ayan

> Cheers
> Bertrand
>
> > Cheers,
> >
> > --
> > Julien Grall