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