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

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

On Tue, Aug 01, 2017 at 02:52:22PM +0300, Andrii Anisov wrote:
> Dear Edgar,
> On 31.07.17 23:42, Edgar E. Iglesias wrote:
> >Yes I'm interested in this.
> It's good to hear at least one vote for the stuff :)
> >  I'm not sure how much time I'll be able to contribute but at least I can 
> > review proposals and hopefully look at implementing a driver/backend that 
> > may be useful for our FPGA platforms.
> I really hope we can start from small things:
> - Could you please describe use-cases you have in your mind. What
> functionality do you expect? It is really important for us, we need some
> side view on the framework.
> - Also it would be good for us to have some view on the coprocessor (fpga?)
> you are going to share using SCF. How is it exposed to the system? Does it
> have mmio, ram, irq, iommu connection, whatever?


I don't really have a defined list of requirements but I can do some initial
hand-waiving :-)

On the ZynqMP we have to classes of HW (on the chip) that I think may benefit.
1. The Cortex-R5s
2. The Programmable Logic (FPGA)

The Cortex-R5s are two real-time co-processors that can be programmed.
They have local RAMs and control registers to reset, halt etc.
I'll leave these out for now, they are probably more similar to the
use-cases you had in mind.

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.

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 I think primarily we would be looking at
a way to lets say, "allocate" and "release" the resources for batch use.

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.

Best regards,

> - Please comment on SCF configuration followup letter [1]
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02124.html
> -- 
> *Andrii Anisov*

Xen-devel mailing list



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