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

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

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



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