On Jun 24, 2011, at 1:02 AM, Matt Evans wrote: > 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.
Would be nice to get PPC32 support as well. - k _______________________________________________ Linuxppc-dev mailing list [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
