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

[Julien Grall <julien.grall@xxxxxxx>]

On 21/04/17 15:42, Andrii Anisov wrote:
> Hello,
Hi,

> On 20.04.17 23:20, Volodymyr Babchuk wrote:
> > Hi Stefano,
> >
> > On 12 April 2017 at 22:17, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> > > On Wed, 12 Apr 2017, Dario Faggioli wrote:
> > > > On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
> > > > > On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> > > > > > This is the most difficult problem that we need to solve as part of
> > > > > > this
> > > > > > work. It is difficult to have the right answer at the beginning,
> > > > > > before
> > > > > > seeing any code. If the app_container/app_thread approach causes
> > > > > > too
> > > > > > much duplication of work, the alternative would be to fix/improve
> > > > > > stubdoms (minios) until they match what we need. Specifically,
> > > > > > these
> > > > > > would be the requirements:
> > > > IMO, this stubdom way, is really really really interesting! :-)
> > > >
> > > > > > 1) Determinism: a stubdom servicing a given guest needs to be
> > > > > > scheduled
> > > > > >    immediately after the guest vcpu traps into Xen. It needs to
> > > > > >    deterministic.
> We will also need another type of application: one which is periodically
> called by XEN itself, not actually servicing any domain request. This is
> needed for a coprocessor sharing framework scheduler implementation.
I don't think we should think in term of type of application supported. 
We should aim to have a generic interface we can maintain based on the 
needs.
We can further restrict access to some interface for a given app. But I 
would rather avoid to have different interfaces for each type of 
application.
Cheers,

--
Julien Grall

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