[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XenSummit 2017] Shared coprocessor framework followup




On 02.08.17 15:58, Edgar E. Iglesias wrote:
Today it's an SMMUv2.
You would need to implement additional ops like [1].

I don't necessarily think so. The context-switch would involve saving and
restoring accelerator state aswell as re-programming the PL.
With allocate/release, we only need to re-program the PL.

Saving the state of the PL might be tricky since we don't know how to
(we don't know the details of the acceelerator ahead of time).
I guess we could somehow let the guest that owns the accellerator
save/restore the state somehow but perhaps that brings us back
in the direction of allocate/release semantics...
In this area context switch means to me a process to prepare a coprocessor to (start or continue) serving another domain tasks. It depends on a coprocessor nature and use-cases what the context switch physically means. And it is up to coprocessor platform driver how ctx_switch_from() and ctx_switch_to() are implemented [2]. Theoretically the framework should be platform agnostic.

BTW, the most up to date sources you can find here [3].

[1] https://github.com/xen-troops/xen/commit/a01f7ccf8bd5e9069f82c6ea6b92e2faca4920d9 [2] https://github.com/xen-troops/xen/blob/vgpu-dev/xen/arch/arm/coproc/coproc.h#L81
[3] https://github.com/xen-troops/xen/tree/vgpu-dev

--

*Andrii Anisov*



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.