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

[Julien Grall <julien.grall@xxxxxxx>]

On 04/05/17 11:03, Andrii Anisov wrote:
> Dear All,
Hi Andrii,

> During the topic implementation I faced a nasty issue with a DomU vgic
> configuration.
> Originally I planned that the partial device tree for DomU is being
> passed to the
> hypervisor from libxl__arch_domain_create, but it is too late to set
> vgic configuration
> at this time. The DomU’s vgic is configured from
> libxl_arch_domain_prepare_config, and
> now it seems it is a proper place to send device_tree to a hypervisor as
> a part of
> configuration.
I am not going to comment on the binding itself, but the idea of sending 
a device_tree to the hypervisor as part of configuration.
As you may have seen in the description of the option "device_tree", it 
is complex to verify the partial device tree because of the libfdt 
design. So without fully auditing libfdt and fixing the holes, this 
suggestion would be a vector attack to the hypervisor.
Whilst I do agree that this could be an interface between the user and 
the toolstack, we shall look into introducing a series of DOMCTL for the 
toolstack <-> hypervisor. What would be the issue to do that?
Cheers,

> Provided that I need the device tree blob even later,
> during device
> tree creation for domU (in libxl_prepare_dtb) I would like to have it
> read from a file
> once and keep it during guest domain creation process.
>
> My problem is that domain creation functions stack mainly operates with
> auto generated
> structures. For my current understanding it means that I have to
> introduce another
> libxl type (f.e. File) which will read device tree file and operate with
> a binary blob.
>
> Understanding the complexity of such a change I would like to hear
> comments about the
> SCF configuration concept and feasibility of passing device tree blob
> from toolstack
> to hypervisor as a part of domain configuration.
>
> *Andrii Anisov*
--
Julien Grall

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