arch: support customized up_cpu_index() in AMP mode

[hujun260]

Summary

support customized up_cpu_index() in AMP mode

Some app with same code runs on different cores in AMP mode, need the physical core on which the function is called.

Impact

arm

Testing

ostest

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not meet the NuttX requirements.

Here's why and how to improve it:

Missing Information:

• Summary:
  • Insufficient Detail: The "How" is vague. Explain exactly how up_cpu_index() is customized and accessed within the AMP context. Provide a code example if possible.
  • No Issue References: Link any related NuttX issues this PR addresses.
• Impact:
  • Incomplete:
    • You mention "arm" but don't specify architectures or boards. Be specific about affected hardware.
    • Address all impact points (build process, documentation, security, compatibility, etc.). Even if the answer is "NO", state it explicitly.
• Testing:
  • Inadequate:
    • Build Host: Specify your development environment's OS, CPU architecture, and compiler version.
    • Target(s): Be very specific about the ARM architectures and boards you tested on. Provide the board configuration names (e.g., board:config).
    • Logs: "ostest" is not descriptive. Include relevant snippets of logs from before and after your changes to demonstrate the problem and the fix.

How to Improve:

1. Expand the Summary: Provide a clear, step-by-step explanation of your changes to up_cpu_index(). Use code examples to illustrate the new behavior.
2. Complete the Impact Assessment: Go through each impact point and provide a "YES" or "NO" answer with a brief explanation.
3. Provide Detailed Testing Information:
   • Specify your build host environment.
   • List all tested ARM architectures, boards, and their configurations.
   • Include relevant log snippets that show the issue before the change and the correct behavior after.

Remember: A well-documented PR significantly increases its chances of being reviewed and merged quickly. Be thorough and provide as much context as possible!

[pussuw]

Isn't up_cpu_index the logical core number (which is only meaningful to the NuttX kernel), not the physical core number? I presume for AMP communication you need the physical core.

[xiaoxiang781216]

Isn't up_cpu_index the logical core number (which is only meaningful to the NuttX kernel), not the physical core number? I presume for AMP communication you need the physical core.

Yes, that's why we have two api now: this_cpu and up_cpu_index. this_cpu is logical core number, up_cpu_index is physical core number.
up_cpu_index always return the real core number regardless CONFIG_SMP setting, on the other hand this_cpu always return 0 if CONFIG_SMP is false after this patch: #13211

[pussuw]

Isn't up_cpu_index the logical core number (which is only meaningful to the NuttX kernel), not the physical core number? I presume for AMP communication you need the physical core.

Yes, that's why we have two api now: this_cpu and up_cpu_index. this_cpu is logical core number, up_cpu_index is physical core number. up_cpu_index always return the real core number regardless CONFIG_SMP setting, on the other hand this_cpu always return 0 if CONFIG_SMP is false after this patch: #13211

This makes sense, but the function description of up_cpu_index is still talking about SMP / logical CPU number, you need to update that too.

[xiaoxiang781216]

@hujun260 look at @pussuw 's suggestion.

[pussuw]

LGTM

[xuxin930]

@hujun260 only POSIX implementation is provided here, no Win implementation
this will block MSVC build

[xiaoxiang781216]

let's check windows before select ARCH_HAVE_MULTICPU, @hujun260

[hujun260]

ok

[hujun260]

#14024

[pussuw]

@hujun260 @xiaoxiang781216 do you have a plan to introduce conversion between logical <-> physical CPU index via the this_cpu() macro in the future ? Now this_cpu() is still equal to up_cpu_index().

[xiaoxiang781216]

@hujun260 @xiaoxiang781216 do you have a plan to introduce conversion between logical <-> physical CPU index via the this_cpu() macro in the future ?

what's conversion do you want?

Now this_cpu() is still equal to up_cpu_index().

it isn't always equals, when SMP is off, up_cpu_index may return nonzero value, but this_cpu always return zero.

[pussuw]

A logical CPU index just an arbitrary number and its value is only meaningful for the operating system code, while the physical CPU index can have meaning in things like interrupt acknowledgement etc. They most definitely do not have to be the same, even though in our case they are, at least atm.

The issue arises when we introduce a platform, that has CPU cores with unequal capabilities e.g. MPFS / Polarfire SoC. It has harts 0..4 but hart0 cannot participate in NuttX SMP as it is less capable than harts 1..4, it does not have an MMU for one example. On the other hand, for interrupt acknowledgment the physical core (hartID) is needed.

This is why some kind of logical <-> physical conversion (other than physical=logical) is inevitably needed. I think Linux handles this via FDT, but we can do with something much simpler.

My question was simply to ask if you were already implementing something for this_cpu(). If not, then I'll do the simple translation that fixes MPFS SMP.

[xiaoxiang781216]

No, this type of mapping can only be handled by arch/chip specific code.

[pussuw]

Yep, I'll add a hook under arch for it