tree abd035a9dcd11ff00e8c9a170c99af541b9dc77c
parent 062ddf58b98fb82a13469be0c4c913605eb6463f
author yonghong-song <yhs@fb.com> 1778330672 +0100
committer GitHub <noreply@github.com> 1778330672 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJp/ywwCRC1aQ7uu5UhlAAA7QUQAFmoEtmWXPCISIa5/MI/ilPB
 hyIRFahLAUynD+zsO0jWq1eWTKDZuwUUy1GUnT1YSiOcaoRRR9uXkoy6bT0+D9pd
 8Pd1IIR++vk+5q40kMlMwPpf/8VVNwcxAKFLj08Lt/ooCf/vxaydB//XggDGgmun
 bf/y5qdFSVKd49ikVIpmTySdteJ6m/2z5y2kgW1hks1CKtiqTZklgzr/XyP+Ku6f
 rTUdi+H69FIx0eKSRy7n1bQJhsd6+kImwGM/pdV8vz+EsVSAcpVxwIP5uAHXCnlZ
 INy4nHLzhG8uuoE2TnhKTElx+LCm0w1U1vWTEuW21DuAkliZZE9X1qUIN4ZP0A/f
 kbe/QttHGfoR7KRBOHqrwo0RCs/EYwsvCrmFzPD1A9lTc0I7l7QwdSlsMnMqhUce
 QTr+zlKrTy3yhTNI92rHhlIWvdJWpIipgxbj3LlgzLft7q+ESVUm2HQboW7qv9bc
 tD/mYBrv8v3SViXM6IdmaJvYJqNPlmnxmMaxiztFHGARlk6o8krYY6CaIFuwzr6K
 EPm3l9+sW41fa24kPXkNsqNc06k2urLO7C9SOfsl6mM1NOn3nE4S39NLhtMQK/7E
 QnjOFqIiWyONrfyVC157iZxIsNMA9QhISGEtMxRxa2pS1d8MwVufdDFPJKr7KbBN
 Jz2MtT9i68y+WQdqoNpo
 =9sXm
 -----END PGP SIGNATURE-----
 

[BPF] Support Stack Arguments (#189060)

Currently, bpf program and kfunc only support 5 register parameters. As
bpf community and use cases keep expanding, there are some need to
extend 5 register parameters by allocating additional parameters on
stack. There are two main use cases here:
1. Currently kfunc is limited to 5 register parameters. In some special
situation, people may want to have more than 5 parameters. One of
example is for sched_ext.
2. Allowing more stack parameters can make bpf prog writer easier since
they do not need to carefully limit the number of parameters for their
programs.

The following is the high-level design:
- Use bpf register R11 as the frame pointer to stack parameters. This is
to avoid mixing stacks due to R10.
  - Stack parameters must be after 5 register parameters.
- All parameters should be at most 16 bytes as ByVal parameters are not
supported.
- Support for cpu v1 to v4 so all cpu versions can use this. A feature
macro __BPF_FEATURE_STACK_ARGUMENT is defined and users can check
whether stack argument is supported or not.

The below is a simple asm code example about stack parameters:
```
  bar:
    /* Retrieve two parameters from the caller of bar(). */
    rX = *(u64 *)(r11 + 8)  // 1st arg
    rY = *(u64 *)(r11 + 16) // 2nd arg
    ...
    /* Prepare the single stack parameters for foo1 */
    *(u64 *)(r11 - 8) = rZ  // 1st arg
    call foo1
    ...
    /* Prepare the single stack parameters for foo2 */
    *(u64 *)(r11 - 8) = rX  // 1st arg
    *(u64 *)(r11 - 16) = rY // 2nd arg
    call foo2
    ...
  foo1:
    /* Retrieve parameter '*(u64 *)(r11 - 8) = rZ' from bar(),
     * and assign the value rZ to rX.
     */
    rX = *(u64 *)(r11 + 8)  // 1st arg
    ...
  foo2:
    /* Retrieve parameters '*(u64 *)(r11 - 8/16) = rZ' from bar(),
     * and assign values rX/rY to rU/rV.
     */
    rU = *(u64 *)(r11 + 8)  // 1st arg
    rV = *(u64 *)(r11 + 16) // 2nd arg
    ...
```

The code patterns in the above try to follow x86_64/arm64 calling
conventions. That is, the first argument is in lower location than
the second argument, etc. The r11 based load should retrieve the value
directly from the caller stack. The r11 based store should push
the value directly on the specificed stack location.

Internally in bpf backend, pseudo insns are generated for
load_stack_arg and store_stack_arg. The BPFMIPeephole pass
changes pseudo insns into proper real bpf insns like the above.