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

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

> 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 that

If you mean hook with vcpu scheduler then we will not. On an SMP
system it could be running vcpus from different domains at the same
time, so we can not rely on the domain is running.
vcoproc scheduling will be independent from vcpu scheduling.

> But I think the design also mentioned asynchronous jobs so there may be 
> situations
> where there is a doorbell to wake up an guest?
Not really sure I've got the question. Coprocessor generated
interrupts would be routed to the domain which context is running on
the coprocessor at the moment of interrupt.

> But I think in my x86 poisioned PoV mind this is similar to an
> PCIe device that has its own MMU.
I'm sorry, I can not compare. I know a little about the x86 world.

> Which brings some more questions - how do we erect the barriers
> such that this "coprocessor" does not destabilize the system
> incase the firmware on the "coprocessors" ends up blowing up?
>
> Are there some other operations to allow the coprocessors
> only to touch specific memory regions?
IOMMU should take care of that. IOMMU setup planned to be a part of
"context", so the framework will take care to switch it.

Sincerely,
Andrii Anisov.

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