Re: [ARM] Native application design and discussion (I hope)

From: Andrii Anisov <andrii_anisov@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien.grall@arm.com>
Cc: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Artem Mygaiev <joculator@gmail.com>,
	george.dunlap@citrix.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [ARM] Native application design and discussion (I hope)
Date: Mon, 24 Apr 2017 19:46:51 +0300	[thread overview]
Message-ID: <fad157ed-dc42-116d-6502-21654f6a3635@epam.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1704211403080.19860@sstabellini-ThinkPad-X260>

Stefano,

On 22.04.17 00:24, Stefano Stabellini wrote:
> The key is to be simple. If it becomes complex, then we are reinventing
> stubdoms.
>
> If the workload needs hardware access, periodical scheduling and it's
> only once instance for all domains, then it's probably better as a
> stubdom.
>
> If the workloads doesn't need hardware access, it's one instance per
> domain, at most it needs to register a timer with Xen, then it would be
> fine as EL0 app. For the EL0 app framework, I'll start from there.
If we are speaking about shared coprocessors framework, we need here 
several things:
  - MMIO access emulation
  - periodic actions (scheduling) which at least will include IOMMU 
reconfiguration and some actions with coprocessor hardware itself in runtime
  - coprocessor interrupts handling and redistribution to target domains

 From one and we would like to have that stuff encapsulated in some 
container (application), somehow separated from XEN. From other hand 
minimal overhead is desired.

-- 

*Andrii Anisov*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel