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

From: Andrii Anisov <andrii_anisov@epam.com>
To: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
	George Dunlap <george.dunlap@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Artem Mygaiev <joculator@gmail.com>
Subject: Re: [ARM] Native application design and discussion (I hope)
Date: Mon, 15 May 2017 16:54:22 +0300	[thread overview]
Message-ID: <6ea35321-22fc-64a5-8c5e-d07a48096883@epam.com> (raw)
In-Reply-To: <CAOcqxo2UN7qgKRx14xVqAvpQHYsSjiXcOE3hRDOwQaVxOE0DGg@mail.gmail.com>


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@lists.xen.org
https://lists.xen.org/xen-devel