[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.