Re: [PATCH RFC 0/4] Initial 32-bit eBPF encoding support

[Jiong Wang <jiong.wang@xxxxxxxxxxxxx>]

On 18/09/2017 22:29, Daniel Borkmann wrote:
> On 09/18/2017 10:47 PM, Jiong Wang wrote:
> > Hi,
> >
> >    Currently, LLVM eBPF backend always generate code in 64-bit mode, 
> > this may
> > cause troubles when JITing to 32-bit targets.
> >
> >    For example, it is quite common for XDP eBPF program to access 
> > some packet
> > fields through base + offset that the default eBPF will generate 
> > BPF_ALU64 for
> > the address formation, later when JITing to 32-bit hardware, 
> > BPF_ALU64 needs
> > to be expanded into 32 bit ALU sequences even though the address 
> > space is
> > 32-bit that the high bits is not significant.
> >
> >    While a complete 32-bit mode implemention may need an new ABI 
> > (something like
> > -target-abi=ilp32), this patch set first add some initial code so we 
> > could
> > construct 32-bit eBPF tests through hand-written assembly.
> >
> >    A new 32-bit register set is introduced, its name is with "w" 
> > prefix and LLVM
> > assembler will encode statements like "w1 += w2" into the following 
> > 8-bit code
> > field:
> >
> >      BPF_ADD | BPF_X | BPF_ALU
> >
> > BPF_ALU will be used instead of BPF_ALU64.
> >
> >    NOTE, currently you can only use "w" register with ALU statements, 
> > not with
> > others like branches etc as they don't have different encoding for 
> > 32-bit
> > target.
>
> Great to see work in this direction! Can we also enable to use / emit
> all the 32bit BPF_ALU instructions whenever possible for the currently
> available bpf targets while at it (which only use BPF_ALU64 right now)?

Hi Daniel,

   Thanks for the feedback.

   I think we could also enable the use of all the 32bit BPF_ALU under 
currently
available bpf targets.  As we now have 32bit register set support, we 
could make
i32 type as legal type to prevent it be promoted into i64, then hook it 
up with i32
ALU patterns, will look into this.

Regards,
Jiong