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

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

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

That's true.


Julien Grall

Xen-devel mailing list



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