Re: [PATCH] docs: fusa: Add requirements for Device Passthrough

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

HI Ayan,

> On 10 Oct 2024, at 11:18, Ayan Kumar Halder <ayankuma@xxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> < snip>
> 
>>> 4) AoU on domain - 1) Domains should not use HVC DCC registers as Xen does 
>>> not emulate them.
>> Xen does not depend on that, the domain does so this is only a Xen expected 
>> behaviour and we should document that Domains shall not use it.
> 
> Agreed, we need to document somewhere that Domains shall not use registers 
> like HVC_DCC, etc which are not properly emulated by Xen.
> 
> Yes, it should not be a part of AoU as Xen's behaviour is not dependent on it.
> 
>> 
>> Xen behaviour if used should be specified.
> Agreed, there should be a document stating the behavior of Xen if non 
> emulated registers are accessed by domains (as an example).
>> 
>>> The AoUs can either be tested or need to be stated explicitly in the safety 
>>> manual.
>>> 
>>>> - "integrator" (word always problematic in Fusa as usually use to bail out
>>>> and give responsibility to someone else) shall and shall not do (for 
>>>> example
>>>> giving access to IOMMU registers to a domain)
>>> The responsibility with the integrator lies for things which cannot be 
>>> tested. For eg Xen has to be built with a particular configuration (eg 
>>> SMMUv3) or a specific CPU errata. Integrator should provide at the most X 
>>> amount of memory for each domain. SMMU (or any specific device) should not 
>>> be assigned to a domain (which should be under Xen's control).
>> Ack
> 
>> 
>>> For some of the AoUs which cannot be tested (eg Bootloader/Firmare needs to 
>>> initialize the DDR, CNTFRQ_EL0 needs to contain the correct system counter 
>>> frequency), the responsibility will lie with the integrator.
>> This is an AoU on the firmware or the platform not on the integrator.
> 
> I agree that this is an AoU on firmware or platform. But we can agree that 
> this AoU cannot be tested by us (within the scope of Xen's safety 
> certification) as we do not know on which hardware platform Xen is deployed. 
> The system integrator (or hardware manufacturer) should know the correct 
> value of system counter frequency. Thus, they should be able to test this.
> 
> Our intention is to keep the scope of Xen's safety certification decoupled 
> from a specific hardware platform. Is this making sense ?

It does as long as the expectations on the hardware are well documented.

> 
>> 
>>>> - interface and what we expect a domain will do with it
>>> This should be covered as part of AoU on domain. We can have more examples 
>>> of this in near future.
>> In my mind interface are for example hypercall numbers and behaviours.
>> I would not expect to find this kind of stuff as AoU.
> 
> Yes, we will be having requirements for the hypercalls. Do you mean this ?

Yes

Cheers
Bertrand

> 
> - Ayan
>