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

[Julien Grall <julien.grall@arm.com>]

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@kernel.org> 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@lists.xen.org
https://lists.xen.org/xen-devel