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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hello Stefano,

>> > The problem with stubdoms is latency and scheduling. It is not
>> > deterministic. We could easily improve the null scheduler to introduce
>> > some sort of non-preemptive scheduling of stubdoms on the same pcpus of
>> > the guest vcpus. It would still require manually pinning vcpus to pcpus.
>> I see couple of other problems with stubdoms. For example, we need
>> mechanism to load mediator stubdom before dom0.
>
> This can be solved: unrelated to this discussion, I had already created a
> project for Outreachy/GSoC to create multiple guests from device tree.
>
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_on_ARM:_create_multiple_guests_from_device_tree
Yes, that could be a solution.


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

>> I'm not very familiar with XEN schedulers. Looks like null scheduler
>> is good for hard RT, but isn't fine for a generic consumer system. How
>> do you think: is it possible to make credit2 scheduler to schedule
>> stubdoms in the same way?
>
> You can do more than that :-)
> You can use credit2 and the null scheduler simultaneously on different
> sets of physical cpus using cpupools. For example, you can use the null
> scheduler on 2 physical cores and credit2 on the remaining cores.
Wow. Didn't know that.


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

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