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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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

Well if they're in a separate security zone, that's not going to work.
You have to have a defined interface between things and sanitize inputs
between them.  Furthermore, you probably want something like a stable
interface with some level of backwards compatibility, which is not
something the internal hypervisor interfaces are designed for.

 -George


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