From: dthaler1968@googlemail.com
To: "'Yonghong Song'" <yonghong.song@linux.dev>
Cc: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: 64-bit immediate instructions clarification
Date: Thu, 25 Jan 2024 17:12:05 -0800 [thread overview]
Message-ID: <259a01da4ff4$adfe9c50$09fbd4f0$@gmail.com> (raw)
In-Reply-To: <9d077ed4-6a30-49db-8160-83d8c525ff3e@linux.dev>
The spec defines:
> As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
> instruction uses a 64-bit immediate value that is constructed as follows.
> The 64 bits following the basic instruction contain a pseudo instruction
> using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
> and imm containing the high 32 bits of the immediate value.
[...]
> imm64 = (next_imm << 32) | imm
The 64-bit immediate instructions section then says:
> Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
> encoding defined in `Instruction encoding`_, and use the 'src' field of the
> basic instruction to hold an opcode subtype.
Some instructions then nicely state how to use the full 64 bit immediate value, such as
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
Others don't:
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
How is next_imm used in those four? Must it be 0? Or can it be anything and it's ignored?
Or is it used for something?
Dave
WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: "'Yonghong Song'" <yonghong.song@linux.dev>
Cc: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: [Bpf] 64-bit immediate instructions clarification
Date: Thu, 25 Jan 2024 17:12:05 -0800 [thread overview]
Message-ID: <259a01da4ff4$adfe9c50$09fbd4f0$@gmail.com> (raw)
Message-ID: <20240126011205.cewhhRXIKCB7T1-i6fbLaHFwIc2Yi-ya_e8xVykE0so@z> (raw)
In-Reply-To: <9d077ed4-6a30-49db-8160-83d8c525ff3e@linux.dev>
The spec defines:
> As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
> instruction uses a 64-bit immediate value that is constructed as follows.
> The 64 bits following the basic instruction contain a pseudo instruction
> using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
> and imm containing the high 32 bits of the immediate value.
[...]
> imm64 = (next_imm << 32) | imm
The 64-bit immediate instructions section then says:
> Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
> encoding defined in `Instruction encoding`_, and use the 'src' field of the
> basic instruction to hold an opcode subtype.
Some instructions then nicely state how to use the full 64 bit immediate value, such as
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
Others don't:
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
> BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
How is next_imm used in those four? Must it be 0? Or can it be anything and it's ignored?
Or is it used for something?
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
next prev parent reply other threads:[~2024-01-26 1:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 20:38 [Bpf] Sign extension ISA question dthaler1968=40googlemail.com
2024-01-16 20:55 ` dthaler1968
2024-01-16 20:55 ` [Bpf] " dthaler1968=40googlemail.com
2024-01-16 22:34 ` Yonghong Song
2024-01-16 22:34 ` [Bpf] " Yonghong Song
2024-01-17 1:56 ` dthaler1968
2024-01-17 1:56 ` [Bpf] " dthaler1968=40googlemail.com
2024-01-17 3:48 ` Yonghong Song
2024-01-17 3:48 ` [Bpf] " Yonghong Song
2024-01-24 2:07 ` Jump instructions clarification dthaler1968
2024-01-24 2:07 ` [Bpf] " dthaler1968=40googlemail.com
2024-01-24 19:33 ` Yonghong Song
2024-01-24 19:33 ` [Bpf] " Yonghong Song
2024-01-26 1:12 ` dthaler1968 [this message]
2024-01-26 1:12 ` [Bpf] 64-bit immediate " dthaler1968=40googlemail.com
2024-01-26 5:34 ` Yonghong Song
2024-01-26 5:34 ` [Bpf] " Yonghong Song
2024-01-26 22:27 ` dthaler1968
2024-01-26 22:27 ` [Bpf] " dthaler1968=40googlemail.com
2024-01-27 3:41 ` Yonghong Song
2024-01-27 3:41 ` [Bpf] " Yonghong Song
2024-01-27 6:56 ` dthaler1968
2024-01-27 6:56 ` [Bpf] " dthaler1968=40googlemail.com
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='259a01da4ff4$adfe9c50$09fbd4f0$@gmail.com' \
--to=dthaler1968@googlemail.com \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=yonghong.song@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.