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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2017-05-05 at 12:28 -0700, Stefano Stabellini wrote:
> On Fri, 5 May 2017, Andrii Anisov wrote:
> > On 24.04.17 21:08, Stefano Stabellini wrote:
> > > The advantages of using EL0 apps are:
> > > - scheduled deterministically
> > > - faster context switch
> > > - lower and deterministic latency
> > > - EL0 apps execution time is accounted appropriately to the guest
> > > that
> > >    they are servicing
> > 
> > Can't the EL0 app be servicing XEN itself?
> 
> Short answer: no.
> 
> Long answer follows. EL0 apps will run in a different context. 
>
I still feel like I am missing something (most likely, due to my
limited knowledge of ARM arch and XenOnARM code). Can you try to
clarify a bit for me what it "in a different context" in this case, and
 why it is important?

> It was
> suggested to keep track of their state in the guest vcpu struct,
> which
> looks like a good idea to me. If we did that, the only way to have an
> EL0 app running without being bound to a specific guest, would be to
> run
> it on the idle vcpu, which I think is a bad idea.
>
Which, FTR, is what we do in Xen for a bunch of things already, i.e.,
softirqs and tasklets.

It's actually a rather effective way of executing some piece of Xen
code synchronously with some event (as softirqs are always checked 'on
the way back' from the hypervisor), which I guess in your case could be
 the trap from the guest vCPU requesting service.

And it should not be hard to give such code access to the context of
the vCPU that was previously running (in x86, given we implement what
we call lazy context switch, it's most likely still loaded in the
pCPU!).

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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