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

[Julien Grall <julien.grall@xxxxxxx>]

On 30/05/17 18:29, Stefano Stabellini wrote:
> On Fri, 26 May 2017, Volodymyr Babchuk wrote:
> > > > > The other issue with stubdoms is context switch times. Volodymyr showed
> > > > > that minios has much higher context switch times compared to EL0 apps.
> > > > > It is probably due to GIC context switch, that is skipped for EL0 apps.
> > > > > Maybe we could skip GIC context switch for stubdoms too, if we knew that
> > > > > they are not going to use the VGIC. At that point, context switch times
> > > > > should be very similar to EL0 apps.
> > > > So you are suggesting to create something like lightweight stubdom. I
> > > > generally like this idea. But AFAIK, vGIC is used to deliver events
> > > > from hypervisor to stubdom. Do you want to propose another mechanism?
> > > There is no way out: if the stubdom needs events, then we'll have to
> > > expose and context switch the vGIC. If it doesn't, then we can skip the
> > > vGIC. However, we would have a similar problem with EL0 apps: I am
> > > assuming that EL0 apps don't need to handle interrupts, but if they do,
> > > then they might need something like a vGIC.
> > Hm. Correct me, but if we want make stubdom to handle some requests
> > (e.g. emulate MMIO access), then it needs events, and thus it needs
> > interrupts. At least, I'm not aware about any other mechanism, that
> > allows hypervisor to signal to a domain.
> The stubdom could do polling and avoid interrupts for example, but that
> would probably not be desirable.
The polling can be minimized if you block the vCPU when there are 
nothing to do. It would get unblock when you have to schedule him 
because of a request.
> > On other hand, EL0 app (as I see them) does not need such events.
> > Basically, you just call function `handle_mmio()` right in the app.
> > So, apps can live without interrupts and they still be able to handle
> > request.
> That's true.
Cheers,

--
Julien Grall

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