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

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

Hello Edgar,


On 01.08.17 17:56, Edgar E. Iglesias wrote:
> On the PL, there's a chunk of programmable logic that allows you to
> create your own custom accellerators or devices.
> Some devices are tied to specific boards (e.g when they depend on specific IO)
> but others are not (for example memory to memory computational accelerators).
> To communicate with these devices, they have memory slave and master ports
> (for register accesses and for DMA). They also have interrupts both ways.
Are master ports behind IOMMU?

> It's possible to reprogram the configuration of the PL and swap accelerators in
> and out on the fly. It's probably going to be too slow for trying to
> context switch between guests
So let us assume it is a FW-less resource we need to share between domains.
Context switch will be stripped to mapping its mmio (or passing mmio 
accesses) next domain to serve and IOMMU configuration switching.
Yep, IOMMU matters.

>   so I think primarily we would be looking at
> a way to lets say, "allocate" and "release" the resources for batch use.
Kind of voluntary preemption?

> If a guest cannot allocate an accelerator, it could fall back to emulation
> or just to using SW libraries until an accelerator slot is available.
What about the thing I called "an access emulation" [1]? From the 
domain's point of view it would be reflected in a delayed response (via 
IRQ or register polling) from an accelerator.
I guess the concept described above is feasible even with current SCF 
code and will not take too much efforts.
[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01935.html
--

*Andrii Anisov*


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