All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>,
	bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
	kernel-team@fb.com
Subject: Re: [PATCH bpf-next v2 1/1] docs/bpf: Add description for CO-RE relocations
Date: Fri, 25 Aug 2023 21:24:23 -0700	[thread overview]
Message-ID: <0aa436da-0b5a-166a-b45d-2ad11a985508@linux.dev> (raw)
In-Reply-To: <20230825224527.2465062-2-eddyz87@gmail.com>



On 8/25/23 3:45 PM, Eduard Zingerman wrote:
> Add a section on CO-RE relocations to llvm_relo.rst.
> Describe relevant .BTF.ext structure, `enum bpf_core_relo_kind`
> and `struct bpf_core_relo` in some detail.
> Description is based on doc-strings from:
> - include/uapi/linux/bpf.h:struct bpf_core_relo
> - tools/lib/bpf/relo_core.c:__bpf_core_types_match()
> 
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>

LGTM with a couple minor nits below.

Acked-by: Yonghong Song <yonghong.song@linux.dev>

> ---
>   Documentation/bpf/btf.rst        |  31 +++-
>   Documentation/bpf/llvm_reloc.rst | 304 +++++++++++++++++++++++++++++++
>   2 files changed, 329 insertions(+), 6 deletions(-)
> 
[...]
> +.. code-block:: c
> +
> + enum bpf_core_relo_kind {
> +	BPF_CORE_FIELD_BYTE_OFFSET = 0,  /* field byte offset */
> +	BPF_CORE_FIELD_BYTE_SIZE   = 1,  /* field size in bytes */
> +	BPF_CORE_FIELD_EXISTS      = 2,  /* field existence in target kernel */
> +	BPF_CORE_FIELD_SIGNED      = 3,  /* field signedness (0 - unsigned, 1 - signed) */
> +	BPF_CORE_FIELD_LSHIFT_U64  = 4,  /* bitfield-specific left bitshift */
> +	BPF_CORE_FIELD_RSHIFT_U64  = 5,  /* bitfield-specific right bitshift */
> +	BPF_CORE_TYPE_ID_LOCAL     = 6,  /* type ID in local BPF object */
> +	BPF_CORE_TYPE_ID_TARGET    = 7,  /* type ID in target kernel */
> +	BPF_CORE_TYPE_EXISTS       = 8,  /* type existence in target kernel */
> +	BPF_CORE_TYPE_SIZE         = 9,  /* type size in bytes */
> +	BPF_CORE_ENUMVAL_EXISTS    = 10, /* enum value existence in target kernel */
> +	BPF_CORE_ENUMVAL_VALUE     = 11, /* enum value integer value */
> +	BPF_CORE_TYPE_MATCHES      = 12, /* type match in target kernel */
> + };
> +
> +Notes:
> +
> +* ``BPF_CORE_FIELD_LSHIFT_U64`` and ``BPF_CORE_FIELD_RSHIFT_U64`` are
> +  supposed to be used to read bitfield values using the following
> +  algorithm:
> +
> +  .. code-block:: c
> +
> +     // To read bitfield ``f`` from ``struct s``
> +     is_signed = relo(s->f, BPF_CORE_FIELD_SIGNED)
> +     off = relo(s->f, BPF_CORE_FIELD_BYTE_OFFSET)
> +     sz  = relo(s->f, BPF_CORE_FIELD_BYTE_SIZE)
> +     l   = relo(s->f, BPF_CORE_FIELD_LSHIFT_U64)
> +     r   = relo(s->f, BPF_CORE_FIELD_RSHIFT_U64)
> +     // define ``v`` as signed or unsigned integer of size ``sz``
> +     v = *((void *)s) + off)

parenthesis not matching in the above.

How about below to a little bit more precise?
   v = *({s|u}<sz> *)((void *)s + off)

> +     v <<= l
> +     v >>= r
> +
[...]
> +
> +CO-RE Relocation Examples
> +=========================
> +
> +For the following C code:
> +
> +.. code-block:: c
> +
> + struct foo {
> +   int a;
> +   int b;
> +   unsigned c:15;
> + } __attribute__((preserve_access_index));
> +
> + enum bar { U, V };
> +
> +With the following BTF definitions:
> +
> +.. code-block::
> +
> + ...
> + [2] STRUCT 'foo' size=8 vlen=2
> + 	'a' type_id=3 bits_offset=0
> + 	'b' type_id=3 bits_offset=32
> +        'c' type_id=4 bits_offset=64 bitfield_size=15

Misalignment in the above.


> + [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
> + [4] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> + ...
> + [16] ENUM 'bar' encoding=UNSIGNED size=4 vlen=2
> + 	'U' val=0
> + 	'V' val=1
> +
> +Field offset relocations are generated automatically when
> +``__attribute__((preserve_access_index))`` is used, for example:
> +
> +.. code-block:: c
> +
> +  void alpha(struct foo *s, volatile unsigned long *g) {
> +    *g = s->a;
> +    s->a = 1;
> +  }
> +
> +  00 <alpha>:
> +    0:  r3 = *(s32 *)(r1 + 0x0)
> +           00:  CO-RE <byte_off> [2] struct foo::a (0:0)
> +    1:  *(u64 *)(r2 + 0x0) = r3
> +    2:  *(u32 *)(r1 + 0x0) = 0x1
> +           10:  CO-RE <byte_off> [2] struct foo::a (0:0)
> +    3:  exit
> +
> +
> +All relocation kinds could be requested via built-in functions.
> +E.g. field-based relocations:
> +
> +.. code-block:: c
> +
> +  void bravo(struct foo *s, volatile unsigned long *g) {
> +    *g = __builtin_preserve_field_info(s->b, 0 /* field byte offset */);
> +    *g = __builtin_preserve_field_info(s->b, 1 /* field byte size */);
> +    *g = __builtin_preserve_field_info(s->b, 2 /* field existence */);
> +    *g = __builtin_preserve_field_info(s->b, 3 /* field signedness */);
> +    *g = __builtin_preserve_field_info(s->c, 4 /* bitfield left shift */);
> +    *g = __builtin_preserve_field_info(s->c, 5 /* bitfield right shift */);
> +  }
> +
> +  20 <bravo>:
> +     4:     r1 = 0x4
> +            20:  CO-RE <byte_off> [2] struct foo::b (0:1)
> +     5:     *(u64 *)(r2 + 0x0) = r1
> +     6:     r1 = 0x4
> +            30:  CO-RE <byte_sz> [2] struct foo::b (0:1)
> +     7:     *(u64 *)(r2 + 0x0) = r1
> +     8:     r1 = 0x1
> +            40:  CO-RE <field_exists> [2] struct foo::b (0:1)
> +     9:     *(u64 *)(r2 + 0x0) = r1
> +    10:     r1 = 0x1
> +            50:  CO-RE <signed> [2] struct foo::b (0:1)
> +    11:     *(u64 *)(r2 + 0x0) = r1
> +    12:     r1 = 0x31
> +            60:  CO-RE <lshift_u64> [2] struct foo::c (0:2)
> +    13:     *(u64 *)(r2 + 0x0) = r1
> +    14:     r1 = 0x31
> +            70:  CO-RE <rshift_u64> [2] struct foo::c (0:2)
> +    15:     *(u64 *)(r2 + 0x0) = r1
> +    16:     exit
> +
> +
[...]

  reply	other threads:[~2023-08-26  4:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25 22:45 [PATCH bpf-next v2 0/1] docs/bpf: Add description for CO-RE relocations Eduard Zingerman
2023-08-25 22:45 ` [PATCH bpf-next v2 1/1] " Eduard Zingerman
2023-08-26  4:24   ` Yonghong Song [this message]
2023-08-26 15:10     ` Eduard Zingerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0aa436da-0b5a-166a-b45d-2ad11a985508@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.