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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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

So it looks like there could be an generic API to deal with
these various operations. And I think you are thinking to hook
it up to the scheduler so that when a guest switches you can
follow with that (similar to how Intel IOMMU VT-x Posted Interrupts
are done). But I think the design also mentioned asynchronous
jobs so there may be situations where there is a doorbell
to wake up an guest? 

But I think in my x86 poisioned PoV mind this is similar to an
PCIe device that has its own MMU.

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?

Thanks.
> 
> Best regards,
> Artem Mygaiev

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