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 -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
