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

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

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 care about following:

AA> Due to the fact that some domain assigned a vcoproc could access coproc when
AA> it is running another domain context, framework will implement iomem access
AA> emulation for domains which are not provided coproc at the moment of access.

Sincerely,
Andrii Anisov.


On Sat, Nov 12, 2016 at 2:04 PM, Artem Mygaiev <joculator@xxxxxxxxx> wrote:
> On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> 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 is be no single way to switch context on
> co-processors, so yes, hypervisor has to know the co-processors.
> The situation is not as bad as having full-scope driver (which is
> implemented in some proprietary hypervisors), we only need to:
> 1. stop
> 2. flush registers
> 3. switch memory context <--- implemented by SMMU in ARM
> 4. restore registers
> 5. start
>
> Best regards,
> Artem Mygaiev

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel