Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Dave Martin <dave.martin@linaro.org>]

On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > On Tue, 28 Aug 2012, Rob Herring wrote:
> > > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > > While it is a PPC doc, we should reuse or extend what makes sense.
> > > 
> > > See section 7.5:
> > > 
> > > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> > 
> > Thanks for the link, I wasn't aware of ePAPR.
> > 
> > The hypervisor node defined by ePAPR is not very different from what I
> > am proposing. Should I try to be compatible with the hypervisor
> > specification above (as in compatible = "epapr,hypervisor-1.1")?
> > Or should I just use it as a reference for my own specification?
> > 
> > Personally I would rather avoid full compatibility with ePAPR.
> 
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
> 
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).
> 
> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.

Some thoughts on this:

We decided that embedding machine instructions into the DT is a fairly
awful idea when discussing how to describe low-level debug UARTs in the
DT.  I don't think it's a lot better in this case (never mind issues
like ARM versus Thumb, endianness etc.)

If we are going to attempt to describe the call interface, we should
do it symbolically, allowing the hypervisor interface code in the kernel
to choose (or, if necessary, generate) the right call wrappers.

We will have this issue for descrbing power firmware interfaces for
example: we already know that this functionality might require an SMC
or HVC instruction to call it, depending on the platform.

A hypervisor with only one call ABI could leave this to be implicit,
providing there is a version number property of similar to allow future
changes to be accommodated.


Cheers
---Dave