Re: [RFC] scf: SCF device tree and configuration documentation

[Andrii Anisov <andrii_anisov@epam.com>]

Hello Ian,


On 05.05.17 17:13, Ian Jackson wrote:
> I read this proposal.
>
> I agree that putting all the details (interrupts, mmio, etc.) in the
> libxl config file is probably undesirable.
>
> AFAICT, there, a particularly coprocessor can be identified as a
> portion of the host's DT.  Is that right ?  The plan seems to be to
> take one such thing (or perhaps, several) and pass it through to "the
> guest".
>
> If these regions of the DT can be marked by this "xen,coproc"
> property, can't we instead identify them (eg in the libxl domain
> configuration) by their DT path ?  So then you could say "please pass
> through coprocessor /aliases/soc/coproc0" or something.
Yep, exactly this approach worked for us when there were no requirement 
to spawn for one guest domain several vcoprocs from one physical 
coprocessor.
That requirement leads to a need of mapping "second" vcoproc mmio ranges 
to different addresses and potentially using another IRQ, in order to 
let a domain treat those devices separately.

> Also, the proposal there does not seem to provide any way to say which
> guest should get any particular coprocessor.
No, its not about getting (owning) a coprocessor for some domain, but 
get a virtual coprocessor (vcoproc).
Actually a vcoproc abstraction is inspired by vcpu abstraction, maybe 
such view would help to get an idea.
Please also refer [1] to get the high level overview of the topic.

>    It talks about "the
> domain" (implicitly, "the" guest) - as if there could only be one.
> Surely this is wrong ?
Yep, several domains (domU) could be created using the same partial 
device tree describing a configuration of virtual coprocessors.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html

-- 

*Andrii Anisov*



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