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

[Julien Grall <julien.grall@linaro.org>]

(Adding Christoffer)

On 06/18/2014 08:38 PM, Stefano Stabellini wrote:
> On Mon, 16 Jun 2014, Julien Grall wrote:
>> DOM0 doesn't provide a generic way to get information about a device tree
>> node. If we want to do it in userspace, we will have to duplicate the
>> MMIO/IRQ translation from Xen. Therefore, we can let the hypervisor
>> doing the job for us and get nearly all the informations.
>>
>> This new physdev operation will let the toolstack get the IRQ/MMIO regions
>> and the compatible string. Most the device node can be described with only
>> theses 3 items. If we need to add a specific properties, then we will have
>> to implement it in userspace (some idea was to use a configuration file
>> describing the additional properties).
>>
>> The hypercall is divided in 4 parts:
>>     - GET_INFO: get the numbers of IRQ/MMIO and the size of the
>>     compatible string;
>>     - GET_IRQ: get the IRQ by index. If the IRQ is not routable (i.e not
>>     an SPIs), the errno will be set to -EINVAL;
>>     - GET_MMIO: get the MMIO range by index. If the base and the size of
>>     is not page-aligned, the errno will be set to -EINVAL;
>>     - GET_COMPAT: get the compatible string
>>
>> All the information will be accessible if the device is not used by Xen
>> and protected by an IOMMU.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>
> 
> 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).

> 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.

-- 
Julien Grall