Re: [Xen-devel] [RFC 09/19] xen/dts: Add hypercalls to retrieve device node information

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 06/19/2014 01:21 PM, Stefano Stabellini wrote:
>>> I know that we talked about this face to face already, but this troubles
>>> me: is it really so uncommon for a device tree node corresponding to a
>>> device to have a key-value pair that is critical for the initialization
>>> of the device?
>>
>> I remembered a chat with Christoffer (I think you were in CC) about
>> specific device properties. But I can't find it in my mailbox.
>>
>> I think the idea was Xen provides the generic properties (regs,
>> interrupts) and we implement device specific properties in a
>> configuration file that could be share with KVM (IIRC, KVM has the same
>> needs).
> 
> What configuration file? Where would it live?
> I would rather avoid forcing the user to specify these properties in the
> VM config file.

I meant an host config file.

>>> The ACPI on ARM people are discussing how to introduce these key-value
>>> pairs in ACPI too, so I wonder if we can really dismiss them so easily
>>> for device assignment.
>>>
>>> Could Xen discard everything that it knows cannot be passed to the guest
>>> (information on clocks and phandles for example), but return to the
>>> toolstack other harmless key-value pairs, such as device specific
>>> configurations? Maybe we could introduce PHYSDEVOP_DTDEV_GET_KEYVALUE.
>>
>> A blacklist won't work here because Xen may return properties that
>> contain a list of phandle (for instance see the SMMU bindings). The name
>> of those properties are not necessary generic.
>>
>> IHMO, need to let the toolstack device whether we need to add specific
>> properties. Those properties can be write down in a configuration file
>> which will be parsed by the toolstack.
> 
> Could we simply remove anything that contains phandles? Is there a way
> to detect if a value is a phandle?

A phandle is only a way to interpret a number. AFAIK, there is no way to
differentiate it.

Regards,

-- 
Julien Grall

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