> I was thinking of something trivial but enough to prove the point.
It is already implemented in a hack'n'slash way.
So we are pretty confident in the approach and looking forward to make
generic and scalable implementation.
And upstreamable, of course.
Sincerely,
Andrii Anisov.
> I was thinking of something trivial but enough to prove the point.
> Something like a very simple accelerator, maybe a data copy accelerator.
> A GPU is certainly not trivial :-)
Indeed.
But we still have targets to reach and shortage in resources to spread
over simple examples ;)
Sincerely,
And
On Wed, 23 Nov 2016, Andrii Anisov wrote:
> Stefano,
>
> Please see my answers below:
> >
> > Thank you for the document, I think is a very good start. I also see the
> > need for this framework. Please add more details about the proposed
> > interface (Xen API, hypercalls, etc) in the next versio
Stefano,
Please see my answers below:
>
> Thank you for the document, I think is a very good start. I also see the
> need for this framework. Please add more details about the proposed
> interface (Xen API, hypercalls, etc) in the next version; I am looking
> forward to it.
We will come up with t
Hi Andrii,
Thank you for the document, I think is a very good start. I also see the
need for this framework. Please add more details about the proposed
interface (Xen API, hypercalls, etc) in the next version; I am looking
forward to it.
On Wed, 16 Nov 2016, Andrii Anisov wrote:
> AM> The situat
> So it looks like there could be an generic API to deal with
> these various operations.
Currently it is designed to be a generic API with platform
(coprocessor) specific hooks.
> And I think you are thinking to hook it up to the scheduler so that when a
> guest
> switches you can follow with t
AM> The situation is not as bad as having full-scope driver (which is
AM> implemented in some proprietary hypervisors), we only need to:
AM> 1. stop
AM> 2. flush registers
AM> 3. switch memory context <--- implemented by SMMU in ARM
AM> 4. restore registers
AM> 5. start
Well, we also need to take
On Sat, Nov 12, 2016 at 02:04:25PM +0200, Artem Mygaiev wrote:
> On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
> wrote:
> > Does this also mean that the hypervisor has to know the co-processors?
> > As in how to start/stop them? And how to tell them to save/restore
> > guest context? Or
On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
wrote:
> Does this also mean that the hypervisor has to know the co-processors?
> As in how to start/stop them? And how to tell them to save/restore
> guest context? Or is there some generic specification for doing this?
Unfortunately there
On Tue, Nov 01, 2016 at 03:57:13PM +0200, Artem Mygaiev wrote:
> Let me explain a bit background of this work.
>
> We see growing amount of use cases for different "co-processors" like
> - GPUs (inside of most modern SoCs)
> - low-power side CPU cores (like ARM Cortex M or R on board with
> Cort
Dear All,
Would you please come up with more comments, ideas or blames on the topic?
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Let me explain a bit background of this work.
We see growing amount of use cases for different "co-processors" like
- GPUs (inside of most modern SoCs)
- low-power side CPU cores (like ARM Cortex M or R on board with
Cortex A cores to handle PM or other tasks)
- DSPs (for example, TI C6000 fami
> 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
On 28/10/16 18:53, Andrii Anisov wrote:
> Dear All,
>
> At this moment we are designing a shared coprocessor framework to be
> introduced into XEN hypervisor.
> Please review an initial draft of the requirements and design overview.
Thankyou for the design doc. An immediate +1 from me, simply for
Dear All,
At this moment we are designing a shared coprocessor framework to be
introduced into XEN hypervisor.
Please review an initial draft of the requirements and design overview.
===
Shared coprocessor framework
15 matches
Mail list logo
