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

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



Julien Grall writes ("Re: [RFC] scf: SCF device tree and configuration 
documentation"):
> I have CCed Ian and Wei to comment on the difficult to describe a such 
> interface in libxl. They may have insights how to do this properly.

Hi.

> @Ian @Wei: Andrii is suggesting to use Device-Tree for describing 
> virtual co-processor as it seems it would be very difficult to do the 
> same with the configuration file. See the suggested binding in [1].

Firstly, I should say that I'm starting fresh on this ARM coprocessor
topic.  So forgive me if I make any obvious mistakes.

> [1] https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg106924.html

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.

Also, the proposal there does not seem to provide any way to say which
guest should get any particular coprocessor.  It talks about "the
domain" (implicitly, "the" guest) - as if there could only be one.
Surely this is wrong ?

Ian.

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

 


Rackspace

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