Messages in this thread | | | From | Luke Nelson <> | Date | Fri, 28 Feb 2020 14:20:11 -0800 | Subject | Re: [PATCH v3 bpf-next] RV32G eBPF JIT |
| |
On Fri, Feb 28, 2020 at 6:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > Luke/Xi, apologies for the slow reponse. (All my RV work is done on > non-payed time, so that's that. :-)) Very nice that you're still > working on it!
No worries, thanks for reviewing!
> > > > - ALU64 DIV/MOD: Requires loops to implement on 32-bit hardware. > > Even though it requires loops, JIT support would be nice. OTOH, arm > doesn't support that either...
We could probably implement this by calling into a helper function for BPF_ALU64 | BPF_DIV/BPF_MOD, but none of the other JITs (e.g., arm,x86) for 32-bit architectures do this. We could add support to rv32 and other architectures in a future patch.
> > - BPF_XADD | BPF_DW: Requires either an 8-byte atomic instruction > > in the target (which doesn't exist in RV32), or acqusition of > > locks in generated code. > > > > Any ideas how this could be addressed for RV32G?
I don't believe there is a simple way to correctly implement BPF_XADD | BPF_DW without hardware support for 64-bit atomic operations, like for other 32-bit JITs.
> In general I agree with Song; It would be good if the 64/32 bit > variants would share more code. RISC-V 64/32 *are* very similar, and > we should be able to benefit from that codewise. > > Pull out all functions are that common -- most of the emit_*, the > parts of the registers, the branch relaxation, and context > structs. Hopefully, the acutal RV32/64 specfic parts will be pretty > small.
Thanks for the suggestion. I'll factor out the common functionality into a header for the next revision.
> Finally; There are some checkpatch issues: run 'checkpatch.pl --strict'. > [...]
I'll fix the rest of the issues you found in the next revision.
> Thanks for the hard work! I'll take it for a spin, with help from the > guide above, this weekend!
Thanks again! - Luke
| |