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

On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > 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. > > >

On Sat, Sep 23, 2017 at 1:41 AM, Jakub Kicinski via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > On Fri, 22 Sep 2017 22:03:47 -0700, Yonghong Song wrote: >> On 9/22/17 9:24 AM, Jakub Kicinski wrote: >> > On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote: >> >> On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:

In BPF, an ADD instruction is defined as a 2 register instruction: 0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def _rr : ALU_RR<BPF_ALU64, Opc, (outs GPR:$dst), (ins GPR:$src2, GPR:$src), "$dst "#OpcodeStr#" $src", [(set

On Sat, Sep 23, 2017 at 10:41:25AM +0200, Jakub Kicinski wrote: > > > Thinking about next steps - do we expect the 32b operations to clear the > > > upper halves of the registers? The interpreter does it, and so does > > > x86. I don't think we can load 32bit-only programs on 64bit hosts, so > > > we would need some form of data flow analysis in the kernel

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessary shifts on x86_64 and improve the performance. Looking through a few bpf programs and it looks like the opportunity is not great, but still nice to have if we have this capability. As you

Hello. I've tried to add some simple arithmetic vector operations to the BPF backend available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

On Mon, Mar 06, 2023 at 05:58:30PM +0100, Roberto Sassu wrote: > If there is no hook registering to inode_init_security, theoretically > the LSM infrastructure should return -EOPNOTSUPP, which causes ocfs2 to > set si->enable to zero, and not execute the line that causes the kernel > to panic. > > The problem would arise if somehow the LSM infrastructure returns zero, >

On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote: > On 06/15/2016 10:14 PM, Alexei Starovoitov wrote: >> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev >> <iovisor-dev at lists.iovisor.org> wrote: >>> This same value for EM_BPF is being propagated to glibc, >>> elfutils, and binutils. >> >> great! >> Can

Hi All, I'd like to propose to upgrade BPF backend to first class citizen. Current status of it: - used with linux kernel on x64, arm64, s390 architectures - projects that use it: perf, tc, ovs - there are few front-ends in the works: . one is translating custom language to C and then using clang/llvm . another is generating llvm IR directly . yet another is using clang rewriter to

On Tue, Feb 27, 2018 at 12:49 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.duyck at gmail.com wrote: >>On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudrala at intel.com wrote: >>>>Patch 1 introduces a new feature bit

On Tue, Feb 27, 2018 at 12:49 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Tue, Feb 20, 2018 at 05:04:29PM CET, alexander.duyck at gmail.com wrote: >>On Tue, Feb 20, 2018 at 2:42 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudrala at intel.com wrote: >>>>Patch 1 introduces a new feature bit

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >>>> You could probably >>>> even handle the Tx queue selection via a simple eBPF program and map >>>> since the input for whatever is used to select Tx should be pretty >>>> simple, destination MAC, source NUMA node, etc, and the

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >>>> You could probably >>>> even handle the Tx queue selection via a simple eBPF program and map >>>> since the input for whatever is used to select Tx should be pretty >>>> simple, destination MAC, source NUMA node, etc, and the

On Mon, Jan 22, 2018 at 6:04 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote: >> On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: >> > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >> > > > > You could probably >> > > > > even handle the Tx queue

On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: > > > You could probably > > > even handle the Tx queue selection via a simple eBPF program and map > > > since the input for whatever is used to select Tx should be pretty > > > simple, destination MAC, source NUMA node, etc, and the data-set > > > shouldn't be too large. > >

On Fri, Apr 20, 2018 at 8:34 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote: >> > > + finfo = netdev_priv(failover_dev); >> > > + >> > > + primary_dev = rtnl_dereference(finfo->primary_dev); >> > > + standby_dev = rtnl_dereference(finfo->standby_dev); >> >

Hi, Quoting Pol Van Aubel (2020-01-21 23:41:48) > Hi, > > Quoting Pavel Hrdina (2020-01-21 12:53:49) > > Thanks for the logs, but it did not help to figure out where the issue > > is. I was hoping to see some error output from the syscall but the line > > that should contain it is empty: > > > > 2020-01-20 19:47:15.589+0000: 8579: debug :