Re: [Xen-devel] Notes on stubdoms and latency on ARM

[Julien Grall <julien.grall@xxxxxxx>]

On 20/06/17 17:23, Volodymyr Babchuk wrote:
> Hi Julien,
Hi Volodymyr,

> On 20 June 2017 at 03:45, Julien Grall <julien.grall@xxxxxxx> wrote:
> > > On 19 June 2017 at 10:54, Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > wrote:
> > >
> > > > > But given the conversation so far, it seems likely that that is mainly
> > > > > due to the fact that context switching on ARM has not been optimized.
> > > >
> > > > True. However, Volodymyr took the time to demonstrate the performance of
> > > > EL0 apps vs. stubdoms with a PoC, which is much more than most Xen
> > > > contributors do. Nodoby provided numbers for a faster ARM context switch
> > > > yet. I don't know on whom should fall the burden of proving that a
> > > > lighter context switch can match the EL0 app numbers. I am not sure it
> > > > would be fair to ask Volodymyr to do it.
> > > Thanks. Actually, we discussed this topic internally today. Main
> > > concern today is not a SMCs and OP-TEE (I will be happy to do this
> > > right in XEN), but vcopros and GPU virtualization. Because of legal
> > > issues, we can't put this in XEN. And because of vcpu framework nature
> > > we will need multiple calls to vgpu driver per one vcpu context
> > > switch.
> > > I'm going to create worst case scenario, where multiple vcpu are
> > > active and there are no free pcpu, to see how credit or credit2
> > > scheduler will call my stubdom.
> > > Also, I'm very interested in Julien's idea about stubdom without GIC.
> > > Probably, I'll try to hack something like that to see how it will
> > > affect overall switching latency
> > This can only work if your stubdomain does not require interrupt. However,
> > if you are dealing with devices you likely need interrupts, am I correct?
> Ah yes, you are correct. I thought about OP-TEE use case, when there
> are no interrupts. In case of co-processor virtualization we probably
> will need interrupts.
>
> > The problem would be the same with an EL0 app.
> In case of EL0 there will be no problem, because EL0 can't handle
> interrupts :) XEN should receive interrupt and invoke app. Yes, this
> is another problem with apps, if we want to use them as devices
> drivers.
Well, this is a bit more complex than that. When you receive an 
interrupt Xen may run a vCPU that will not use that app. So you have to 
ensure the time will not get accounted for it.
The more I read the discussion, the more I think we should look at 
optimizing the stubdom case. Xen EL0 should only be used for tiny 
emulation for a given domain. Otherwise you end up to re-invent the domain.
Cheers,

--
Julien Grall

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