Re: [Xen-devel] [PATCH v3 2/2] xen/arm : emulation of arm's PSCI v0.2 standard

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-07-10 at 16:04 +0530, Parth Dixit wrote:

> > It seems like the SMC Calling Convention doc which I referenced covers
> > the requirements here.

FWIW I asked Charles (the author of the spec) about this, his response
is below (with permission). I've not yet looked at your v4 with this in
mind.

Ian.
---------


> For functions which have both an SMC32 and SMC64 variant is it it
> permissible for a cpu to call the entry point which doesn't correspond
> to the mode it is in? From the SMC calling convention spec I think it
> is illegal for an aarch32 cpu to call an SMC64 interface but permissible
> for an aarch64 cpu to call SMC32, since not all interfaces have an
> SMC64 variant. Is that true even when an SMC64 variant is defined?

This is valid for the SCM calling convention but not in general, for
PSCI, in fact the spec requires INVALID_PARAMETERS to be returned in the
case the execution state of the caller (AArch32/64) doesn't match for
the ID. It' valid for the SMC calling convention as you may have calls
which make sense as 32 bit calls in the first place, and for which there
is no 64 equivalent. There may even be cases where a caller specifically
wants to use a 32 bit variant for a given SMC based API (though I can't
think of any off the top my head). For the PSCI calls that are affected
by this issue it would have been complicated to allow this. It would
have been confusing for a 64 bit caller to call say SUSPEND as 32 bit,
but obviously would expect to be resumed as 64.


> What is the expected behaviour if the top bits of xN are non-zero for
> an aarch64 cpu calling an SMC32 interface?

Results are passed in Wx and returned in Wx, so I would expect the
implementer is not required to preserve upper words, as the SMC32
calling convention is dictating use of 32 bit widths in the first place
for parameters and returns

When you load into a Wx it will trash the upper word (make it zero). So
coming into the function you'd expect there are zeros there anyway.
Returns should be through Wx so an implementation should not use upper
words when returning values, nor should the callee assume anything
there.

> Is it permissible to clobber the top bits of the return register in
> this case?

Yup, in theory there should zeros there.

> Are cpus allowed to mix and match the use of v0.1 and v0.2 interfaces
> (assuming both have been advertised to them)?
>
> Is there any requirement to call e.g. VERSION before using other v0.2
> interfaces?

Well in an ACPI world we are going to be explicitly linking to PSCI v0.2
and beyond. So there is no need to support both there. On an DT world
you do have the complication that somebody could in theory supply the
original PSCI. However in that case the DT should be describing that.

PSCI_VERSION will come more into its own when we rev PSCI itself, as it
will always be a mandatory API going forward.



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