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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-06-19 at 13:25 +0100, Julien Grall wrote:
> 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.

I think this is basically unavoidable. There is simply no sane way to
expose the necessary stuff from the actual dtb.

My opinion is that we should aim to get something which has the
underlying moving parts (mmio and irq mapping etc) working and in tree
sooner rather than later and leave the question of the sharp edges on
the UI until later.

Regardless of what syntactic sugar we add in the future we should always
have the lowlevel "inject a snippet of dts" interface as an option, and
that is all we really need to implement on the first pass.

A host config file mapping some useful string to such snippets is a nice
simple enhancement to that (and if it's already implemented, great, but
it's not mandatory on this pass IMHO).

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

Correct, it's just a number which the driver knows (by virtue of the
name etc) happens to be a phandle.

Ian.


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