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

From: Volodymyr Babchuk <vlad.babchuk@gmail.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrii Anisov <andrii_anisov@epam.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	george.dunlap@citrix.com, Xen Devel <xen-devel@lists.xen.org>,
	Artem Mygaiev <joculator@gmail.com>
Subject: Re: [ARM] Native application design and discussion (I hope)
Date: Fri, 21 Apr 2017 19:08:25 +0300	[thread overview]
Message-ID: <CAOcqxo0bb6A4SuU9uzfNU__eaC1xA4UqALHLjQRdhSfOB7Gp5A@mail.gmail.com> (raw)
In-Reply-To: <79bfc330-98ab-5a7c-26f7-c47dce8dd71c@arm.com>

Hi Julien,

On 21 April 2017 at 18:49, Julien Grall <julien.grall@arm.com> wrote:
>
>
> 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.
Probably, we can try another approach: allow application to register hooks
in hypervisor: i.e. hook on MMIO, hook on SMC, hook on timer and so on.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@gmail.com

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