From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrii Anisov Subject: Re: [ARM] Native application design and discussion (I hope) Date: Fri, 21 Apr 2017 17:42:08 +0300 Message-ID: References: <1492020822.3287.33.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5311279791187840337==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Volodymyr Babchuk , Stefano Stabellini Cc: Dario Faggioli , Xen Devel , Julien Grall , george.dunlap@citrix.com, Artem Mygaiev List-Id: xen-devel@lists.xenproject.org --===============5311279791187840337== Content-Type: multipart/alternative; boundary="------------A0A1E5C9284A182B1ACAE5E3" --------------A0A1E5C9284A182B1ACAE5E3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, On 20.04.17 23:20, Volodymyr Babchuk wrote: > Hi Stefano, > > On 12 April 2017 at 22:17, Stefano Stabellini 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. -- *Andrii Anisov* *Lead Systems Engineer* *Office: *+380 44 390 5457 *x* 66766 *Cell: *+380 50 5738852 *Email: *andrii_anisov@epam.com *Kyiv**,* *Ukraine *(GMT+3)*epam.com * CONFIDENTIALITY CAUTION AND DISCLAIMER This message is intended only for the use of the individual(s) or entity(ies) to which it is addressed and contains information that is legally privileged and confidential. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. All unintended recipients are obliged to delete this message and destroy any printed copies. --------------A0A1E5C9284A182B1ACAE5E3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hello,

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.

    

    

    
-- 

      
 Andrii Anisov 

      
 Lead
            Systems Engineer 

      
 

      
 Office: +380
            44 390 5457 x 66766  
        Cell: +380 50
            5738852   Email: andrii_anisov@epam.com
      

      
 Kyiv, Ukraine (GMT+3)   epam.com 

      
 

      
 
          CONFIDENTIALITY CAUTION AND DISCLAIMER

          This message is intended only for the use of the individual(s)
          or entity(ies) to which it is addressed and contains
          information that is legally privileged and confidential. If
          you are not the intended recipient, or the person responsible
          for delivering the message to the intended recipient, you are
          hereby notified that any dissemination, distribution or
          copying of this communication is strictly prohibited. All
          unintended recipients are obliged to delete this message and
          destroy any printed copies.  

      
 

    

  


--------------A0A1E5C9284A182B1ACAE5E3--


--===============5311279791187840337==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============5311279791187840337==--