[PATCH] shared processor hcalls use wrong cpu id?

[Joel Schopp]

This is a great catch.

>  The platform documentation is not terribly explicit about this, but
> the shared processor-related hcalls which take a processor number
> parameter (H_REGISTER_VPA, H_CONFER, H_PROD) expect that number to be
> the "hardware" id -- that is, the number taken from the
> ibm,ppc-interrupt-server#s property of the cpu's OF device node.  Right
> now, we're passing the Linux "logical" cpu id to these calls.

Logical and physical used to be the same for awhile.  I guess Dave E.
and I missed this when converting to logically numbering starting at 0.

>
> We're still running tests to determine whether this fixes some of the
> issues we're seeing; but I thought this was important enough to get out
> for review and to make sure I'm on the right track.  The patch is pretty
> rough (e.g. I don't think we want to panic if H_CONFER fails for some
> reason).

I think if H_CONFER fails we can just go on with our lives.  It is a
performance thing, not a correctness thing.

> Also note that I changed the H_CONFER call in the lock code to pass -1
> (all cpus) since it's not very clear to me how the lock holder is
> recorded in the spinlock.

This will have to be fixed as well.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/