[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.


> 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.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.