[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1209131206510.15568@kaball.uk.xensource.com>
Date: Thu, 13 Sep 2012 12:12:54 +0100
From: Stefano Stabellini <stefano.stabellini@...citrix.com>
To: Dave Martin <dave.martin@...aro.org>
CC: Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>,
Ian Campbell <Ian.Campbell@...rix.com>,
"arnd@...db.de" <arnd@...db.de>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"Tim (Xen.org)" <tim@....org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Vrabel <david.vrabel@...rix.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Marc Zyngier <Marc.Zyngier@....com>
Subject: Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Dave Martin wrote:
> On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > - 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.
I completely agree with Dave.
I have no problems adding a symbolic property to say "we are using hvc
with parameters on registers". I just want to avoid having actual
machine instructions (and potentially dealing with executing them) into
the DT.
Maybe we could have a "calling-convention" property that can be "xen"
or something else. When a new hypervisor vendor comes along it can
change the value of "calling-convention" to "foo".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists