Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

On 12.05.17 21:47, Volodymyr Babchuk wrote:
> vcoproc driver should be able to work with real HW, probably it will
> handle real IRQs from device, we need one instance of driver per
> device, not per domain. Andrii can correct me, but vcoproc framework
> is not tied to vcpus, so it can work in context of any vcpu. Thus, it
> will be accounted for that vcpu, that happened to execute at current
> moment. Probably, this is not fair.
I guess the mmio access emulation should be accounted per domain's vcpu. 
Context switching - per idle vcpu (xen itself).
Should it be two different "native apps"?

> Can we run vcoproc driver in a stubdomain? Probably yes, if we can
> guarantee latency (as if in real time system). Just one example: 60FPS
> displays are standard at this time. 1/60 gives us 16ms to deliver
> frame to a display. 16ms should be enough to render next frame,
> compose it, deliver to a display controller. Actually it is plenty of
> time (most of the time). Now imagine that we want to share one GPU
> between two domains. Actual render tasks can be very fast, lets say 1
> ms for each domain. But to render both of them, we need to switch GPU
> context at least two times (one time to render Guest A task, one time
> to render Guest B task). This gives us 8ms between switches. If we
> will put vcoproc driver to a stubdomain, we will be at mercy of vCPU
> scheduler. It is good scheduler, but I don't know if it suits for this
> use case. 8ms is an upper bound. If there will be three domains
> sharing GPU, limit will be 6 ms. And, actually, one slice per domain
> is not enough, because domain may be willing to render own portion
> later. So, 1 ms will be more realistic requirement. I mean, that
> stubdom with coproc driver should be scheduled every 1ms not matter of
> what.
> With native apps (or some light stubdomain) which will be scheduled
> right when it is needed - this is much easier task.
>
> At least, this is my vision of vcoproc driver problem. Andrii can
> correct me, if I'm terribly wrong.
All above is correct enough.

--

*Andrii Anisov*



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