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

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

On Tue, Aug 01, 2017 at 08:04:09PM +0300, Andrii Anisov wrote:
> 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?

Yes, they are.

> 
> >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.

OK. I think the PL is more like a firmware enabled resource.
The PL configuration needs to be loaded much like firmware
otherwise the accelerators can't change shape and all guests
must use the same kind.

For example, one guest might want a crypto accelerator while
another might want some kind of machine-learning accelerator.

I think each guest may want to provide it's own accelerator "config".


> >  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?

Right. That could be a start.
In the future perhaps it makes sense to context-switch.

> 
> >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.

I'll have a look, thanks!

Cheers,
Edgar

> 
> [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