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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hi Dario,

>>> Explanation of what EL0 apps are. What should be their interface with
>>> Xen? Could the interface be the regular hypercall interface? In that
>>> case, what's the benefit compared to stubdoms?
>> I imagined this as separate syscall interface (with finer policy
>> rules). But this can be discussed, of course.
>
> I think that's a natural place to start.  But then you start thinking
> about the details: this thing needs to be able to manage its own address
> space, send and receive event channels / interrupts, &c &c -- and it
> actually ends up looking exactly like a subset of what a stubdomain can
> already do.
Actually, I don't want it to handle events, interrupts and such. I see
it almost as a synchronous function call. For example. when you need
something from it, you don't fire interrupt into it. You just set
function number in r0, set parameters in r1-r7, set PC to an entry
point and you are good to go.

> In which case -- why invent a new interface, instead of just reusing the
> existing one?
Hypercalls (from domains) and syscalls (from apps) are intersecting
sets, but neither is subset for other. One can merge them, but then
there will be calls that have meaning only for apps and there will be
calls that are fine only for domains. Honestly, I have no strong
opinion, which approach is better. I see pros and cons for every
variant.

>>> 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.
>
> There are a couple of options here.  You could do something like the
> Xoar project [1] did, and have Xen boot a special-purpose "system
> builder" domain, which would start both the mediator and then a dom0.
Wow. That's very interesting idea.

>>> Then, we could add a sched_op hypercall to let the schedulers know that
>>> a stubdom is tied to a specific guest domain.
>> What if one stubdom serves multiple domains? This is TEE use case.
> Then you don't make that hypercall. :-)  In any case you certainly can't
> use an EL0 app for that, at least the way we've been describing it.
That depends on how many right you will give to an EL0 app. I think,
it is possible to use it for this purpose. But actually, I'd like to
see TEE mediator right in hypervisor.

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

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