Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

> Thankyou for the design doc.  An immediate +1 from me, simply for the
> doc existing :)

Thank you for you interest and comments.

> Forgive my ignorance (I am an x86 person, and given the CC list, I guess
> this is talking about ARM systems), but what are coprocessors and what
> might I do with one?

Well coprocessor could be a some processing unit inside a SoC which is
running some firmware and supplementing primary processor functions.
F.e. GPU, DSP, some FPGA inside a SoC.
The living example is a GPU sharing implemented for the ARM based SoC.
BTW, the xengt implements pretty close approach and is a pure x86
world solution.

> > It is targeted capability of different domains to run concurrently different
> > firmware on the coproc.
> I cant parse this sentence.  I presume you mean that the purpose of this
> framework is to provide a mechanism for Xen to share a coprocessors
> resource between multiple domains?

Maybe it should be reworded. I mean that coprocessors are entities
which are running some firmware to perform their tasks. So different
domains in their time slice could run different versions of firmware
on the same coprocessor.
It is mentioned here to stress that domains contexts are totally
independent (both for processed data and for firmware code).

> Grammar nit.  Either "Provide coprocessor resource sharing between..."
> or "Provide sharing of coprocessor resources between..."

Will take "Provide sharing of coprocessor resources between...".


> Does it need to only be configurable at system startup?  There is often
> more flexibility by having a default configuration at system start (so
> dom0 can use the resources), which can later be altered by toolstack policy.

I did mean that hypervisor, what starts first, checks what
coprocessors within the system would be shared, own them and provide
to a framework. Providing some of those resources to dom0 would not a
big deal: just assign a vcoproc to the domain. And yes, it could be a
default configuration.

>
> Considering the latter option, even if you don't implement support at
> first, tends to lead to a cleaner design, but of course it does depend
> heavily on the details of the situation.

Definitely we would tailor the design along with an implementation.

> > * MMU-enabled SoC with MMU-protected coprocessor(s)
> Right - definitely ARM then, but it took me until half way through the
> document to work this out.

You know, it was specified ARM based SoC here. At some point it was
removed such a dependency. Inspired by the already mentioned xengt.

> I would be tempted to extend this slightly, and specify that there
> should be a mechanism for the toolstack to query all of this information
> at arbitrary points in time.

It should be covered here:
>
> > Runtime configuration of scheduling algorithm per instance of shared
> > --------------------------------------------------------------------
> > coprocessor
> > -----------
> >
> > There will be a initial domain tool implemented which will provide a CLI for
> > runtime monitoring of shared coprocessors instances available, per-domain/
> > per-coproc instance list of vcoproc and runtime setup of the scheduler per
> > each coprocessor instance.

Maybe it needs some rewording.

> Do you mean that, ideally, Xen can fully context switch a coprocessor
> behind the back of domU, and the domU driver need not know or care about
> the difference?
You've got the point.

> And, where that isn't possible, some virtual hooks could be introduced
> to the domU driver so domU can opt into sharing when it has a compatible
> driver?
Yes, due to specifics of SoC implementation pure solution could be
inefficient, not secure or even impossible. In this case
drivers/firmware could be modified to cooperate with coprocessor
sharing framework in XEN.
This part could be architecture (coprocessor) specific, or machine
(SoC) specific.

Sincerely,
Andrii Anisov.

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