Re: Virtualization difficulty -- phandles

[Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 07/12/2017 09:23 PM, Cyril Novikov wrote:
> On 7/12/2017 10:10 AM, Florian Fainelli wrote:
>> On 07/11/2017 11:15 PM, Cyril Novikov wrote:
>>> Hi, all!
>>>
>>> The product that I work on supports physical device assignment (aka
>>> "pass-through") to virtual machines, which means we need to take
>>> portions of the physical FDT and include them in the guest FDT. This
>>> needs to happen automatically in software.
>>>
>>> The problem is phandles, because we cannot identify them in the blob and
>>> therefore can't find any dependent devices/nodes that also need to be
>>> included in the guest FDT. So the process cannot be fully automated. We
>>> can't even advise the user what other devices should be assigned to the
>>> VM. The hypervisor runs or bare metal, so having to parse the source DTS
>>> files for this is very inconvenient.
>>>
>>> Would it be possible to add metadata properties to the binary FDT
>>> format, which would identify other property cells that are in fact
>>> phandles? It could be a per-node property or a single root node
>>> property, up to you guys. DTC would then automatically generate the
>>> metadata property along with the phandle property when compiling the
>>> DTS.
>>
>> phandles are already per-node properties, they are not quite different
>> from normal properties actually. If a node is referred to by other
>> nodes, the DTC compiler would add a phandle = <N> (and maybe even
>> linux,phandle = <N> depending on options passed to it) where N is a
>> global integer that keeps being incremented every time a new phandle is
>> generated.
>>
>> When you strip or create new nodes from a base blob for your virtual
>> machine, either the node is still existing, in which case its phandle
>> property (if existing) is still valid and can still be referenced to, or
>> it is a new node and then you can control how to allocate new phandle
>> integers.
>>
>> I guess I am just not clear on what problem you are seeing with phandles
>> based on your description of what you want to do?
> 
> Maybe I should have worded it differently: the problem is with phandle
> references rather than phandle properties themselves, does it make it
> more clear?

It does, thanks.

> There is no way to know that a certain aligned 4 byte
> sequence is a phandle that references another part of the FDT. You can
> for some standard properties whose format is known not only to the
> driver, but you can't in general. That makes it impossible to analyze
> and detect dependencies between different parts of the FDT automatically.

I see what you mean now, there is indeed no way to tell whether a
property that has an integer is just a normal integer versus an integer
corresponding to a phandle.

You could argue that property that specify a phandle should have a name
that suggests so, like "phy-handle" but then this stops working with
e.g: gpios that are (at least with Linux) specified as e.g: reset-gpios.
In any case, you would have to have some sort of heuristic built into
your FDT mangling code that tries to check if a given property is
designating a phandle as opposed to having a more robust approach...

> 
> I think this situation is solvable with automatically DTC-generated
> metadata. I'm also interested if there are other hypervisor vendors that
> had to deal with this and how big is the demand for a solution. If we
> are the first one, at least let it register that there's a problem and
> interest in addressing it.

That would work, I have not heard of a similar problem with the
hypervisor folks that I worked with, but AFAIR they were generating
their DTS almost from scratch as opposed to mangling/passing through
parts of an existing one.
-- 
Florian