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