-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support riscv jit to provide #3089
Conversation
Master branch: 7e062cd |
We found that 32-bit environment can not print bpf line info due to data inconsistency between jited_ksyms[0] and jited_linfo[0]. For example: jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c We know that both of them store bpf func address, but due to the different data extension operations when extended to u64, they may not be the same. We need to unify the data extension operations of them. Signed-off-by: Pu Lehui <pulehui@huawei.com>
Add support for riscv jit to provide bpf_line_info. We need to consider the prologue offset in ctx->offset, but unlike x86 and arm64, ctx->offset of riscv does not provide an extra slot for the prologue, so here we just calculate the len of prologue and add it to ctx->offset at the end. Both RV64 and RV32 have been tested. Signed-off-by: Pu Lehui <pulehui@huawei.com>
The insn_to_jit_off passed to bpf_prog_fill_jited_linfo should be the first byte of the next instruction, or the byte off to the end of the current instruction. Signed-off-by: Pu Lehui <pulehui@huawei.com>
Master branch: 1626f57 |
The members of bpf_prog_info, which are line_info, jited_line_info, jited_ksyms and jited_func_lens, store u64 address pointed to the corresponding memory regions. Memory addresses are conceptually unsigned, (unsigned long) casting makes more sense, so let's make a change for conceptual uniformity. Signed-off-by: Pu Lehui <pulehui@huawei.com>
The members of bpf_prog_info, which are line_info and jited_line_info store u64 address pointed to the corresponding memory regions. Memory addresses are conceptually unsigned, (unsigned long) casting makes more sense, so let's make a change for conceptual uniformity. Signed-off-by: Pu Lehui <pulehui@huawei.com>
We have unified data extension operation of jited_ksyms and jited_linfo into zero extension, so there's no need to cast u64 memory address to long data type. Signed-off-by: Pu Lehui <pulehui@huawei.com>
e7b6c23
to
667f35b
Compare
Master branch: 4b4b4f9 Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=645930
conflict:
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=645930 irrelevant now. Closing PR. |
Pull request for series with
subject: Support riscv jit to provide
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=645930