Hi,
Inspired by Eric Dumazet's x86-64 compiler for Berkeley Packet Filter programs, I've written a BPF compiler for 64-bit PowerPC. Although it hasn't finished its strenuous testing regime, I'll have intermittent net access for a couple of weeks so thought I'd post it for feedback now and submit a 'proper' version when I'm back. It's a fairly simple code generator, following a similar structure to the x86 version. The filter programs are an array of opcode/constant/branch destination structs, and can perform arithmetic/logical/comparison operations on two virtual registers A and X, loads from packet headers/data and accesses to local variables, M[]. Branching is also supported, but only forwards and only within the extent of the program. I would probably describe this as more of a "static template binary translator" than a "JIT" but have kept naming consistent :) Features include: - Filter code is generated as an ABI-compliant function, stackframe & prologue/epilogue if necessary. - Simple filters (e.g. RET nn) need no stackframe or save/restore code so generate into only an li/blr. - Local variables, M[], live in registers - I believe this supports all BPF opcodes, although "complicated" loads from negative packet offsets (e.g. SKF_LL_OFF) are not yet supported. Caveats include: :) - Packet data loads call out to simple helper functions (bpf_jit.S) which themselves may fall back to a trampoline to skb_copy_bits. I haven't decided whether (as per comments there) it would be better to generate the simple loads inline and only call out in the slow case. - Branches currently generate to "bcc 1f; b <far dest>; 1:" or "bcc <near dest> ; nop" so either case is the same size. Multiple passes of assembly are used (the first gets an idea of how big everything is and what features are required), the next generates everything at accurate size, the third generates everything with accurate branch destination addresses); I intend not to nop-pad the short branch case but changing code size may result in more passes and a 'settling-down period'. Kept simple for now. - Anyone running PPC64 little-endian is doing something both interesting and unsupported for this work :-) (There are some trivial endian assumptions.) Tested in-situ (tcpdump with varying complexity filters) and with a random BPF generator; I haven't verified loads from the fall back skb_copy_bits path. Bug reports/testing would be very welcome. Cheers, Matt _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
