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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 19 Jun 2014, Julien Grall 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@xxxxxxxxxx>
> >> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> >> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>
> > 
> > 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.


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

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