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

[Christoffer Dall <christoffer.dall@linaro.org>]

On 19 June 2014 13:58, Julien Grall <julien.grall@linaro.org> wrote:
> (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).
>

Yeah, experience just shows us that when you start exposing the raw
hardware information to user space or through to VMs without have
semantic control over them, then you will very likely end up in a lot
of trouble.

It really should be able to limit the properties of devices that you
want to export to a reasonable set through a well-defined API.

If you have an extremely complicated device with interesting
inter-dependency, chances are you're going to need a device-specific
user space driver to couple devices, tie inter-dependent devices
together when you describe the machine to your VM, etc.  The API
suggested should take care of the common generic case.

The suggestion about a VM config file was more of a loose-thought if
we start having a bunch of networking devices that have special
properties and we wish to support passthrough of these on both Xen and
KVM, then keeping device-specific data in a config file may be a way
to accomplish that.  This is pretty much speculation and loose ideas
at this point.

Personally, I would prefer doing something along the lines of what
Julien suggest and add necessary properties as needed.  If it turns
out you need a lot more information about devices someone actually
tries to pass through to VMs, then revisit the issue.  This patch
doesn't seem to suggest an awfully complicated ABI that will cause a
lot of headache to maintain in the future or anything like that.

My 2 cents.

-Christoffer