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

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

On 05/05/2017 04:27 PM, Andrii Anisov wrote:
Hello Julien,

On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)

On 04/05/17 17:13, Andrii Anisov wrote:

Hi Andrii,

On 04.05.17 15:46, Julien Grall wrote:

I understand these concerns, but not sure should we be scared of
from a domain privileged enough to run domains?

Whilst the domain is privileged enough to run domains, the
configuration can be provided by a user (for instance in cloud
environment). So you cannot trust what the user provided and any
missing invalidation would lead to a security issue (see XSA-95 [1]
for instance).

That's why we specifically said only trusted device tree should be
used with the option "device_tree".
I see. But I also could state the same.
I would rather avoid to take this approach until we explored all the

We took this approach for platform device passthrough because we
considered it would only be used for embedded platform where
everything will be under control.

In the case of virtual co-processor, I can see a usage beyond embedded
so we would need to deal with non-trusted input.
Yep, it's one of our targets to spread SCF beyond the embedded world.
Also, I do believe that the domain creation should be limited to
create the domain and not configuring the devices other than the
strict necessary. For anything else (UART, co-processor),
But vgic is configured at the earliest stages of the domain creation. So
we have to know at the moment which IRQs would be injected into the
domain. And that is my current problem.

No, the vGIC only needs to know the maximum number of interrupts it
can handle. You don't need to route them at that time.

Currently, the toolstack is deciding on the number of spis supported
(give a look at nr_spis).

IHMO, the toolstack should be able to figure out the number of
interrupts required by the virtual co-processors and then update
nr_spis accordingly.
This will lead to the need of parse (and maybe reads dtb file) first
here. Then one more time on DomU device tree generation.

The code is not set in stone. It can be reworked to avoid that.

The DOMCTL createdomain does not scale for things like co-processors.
It is only here to initialize the bare minimum for a domain. You could
create new DOMCTL to handle co-processors and call them afterwards
from libxl__arch_domain_create.
It is done in such way now. From libxl__arch_domain_create another
domctl sends a pfdt blob to hypervisor for SCF configuration.

Passing an fdt blob to the hypervisor should be used at the last resort. Whilst I agree it would be difficult to get a suitable interface between the user and the toolstack, C allows a lot of freedom to create suitable structure. So I still don't understand why you want to use a device tree between the toolstack and the hypervisor.


Julien Grall

Xen-devel mailing list



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