From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4660EC10F14 for ; Tue, 16 Apr 2019 07:47:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F05F02073F for ; Tue, 16 Apr 2019 07:47:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="yv+Y8lpq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728611AbfDPHrO (ORCPT ); Tue, 16 Apr 2019 03:47:14 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:56104 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727845AbfDPHrO (ORCPT ); Tue, 16 Apr 2019 03:47:14 -0400 Received: by mail-wm1-f68.google.com with SMTP id o25so23989692wmf.5 for ; Tue, 16 Apr 2019 00:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=0Zmi44RmepL3ugmtxZhsUnTuj0oUJ4BCQZi+wmxEsiQ=; b=yv+Y8lpqiuq6+04xqrLNfrC6bcajiEAOYQ8gZ7kHQjpkX2ClZvdRLVN6QPHHkJzydu ICI7Ej+c9Pg2cunSNpOYYNFCpAkGF2aSLdPOuj3p62QXsG2HwhDVd7MSEqsXLDD5slyE RlXoGTg/JYgIrpTSzy/e/5yYNTHO+SDVq71vKjRSYKYMFI++dN1ympvuRvdldrzEOkAp +zNHFHwSBgX97G1BRJCGGjXPbbt2S1BJxObCT3dDfsZKgkVNQycR9aTHeFwGTsQAwTIg Y264fTeD5w5uyKwCECeidQsHoWl7IrUUsIEa48AmQFJSRmVQHiF5RCXqJy55WVc4EYpS X+LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=0Zmi44RmepL3ugmtxZhsUnTuj0oUJ4BCQZi+wmxEsiQ=; b=scFbKBtBKwnowAdYDr7BMJsMGsVivAAJyljJNwO9d9plkP3gI1BLE1QT+15YIogBwR tjeww20WCPg2NOvENOwDF96z00U5Pnw33vCw6Amr32sPVGjs5LtnEsG/1wcjAw+Mheer 4/Tj/bw0oyId/LH3RahNd90QyuXIA7yI1xXt+5mlR8jF7sQSV19cqOEt0yCzqYevFlew Rl1OEp5SrWkom2EIeMdlr4ZmDC3mBkElOPQNGHmFbsj9V8yJo9FXxw79dv7ZAyibcVa9 2zWNQBKPgP805PzoAPvBaT7PKTWpBIDve27DqITaQQTGBYosOGePZMuZdIx2sXup1abw jDrg== X-Gm-Message-State: APjAAAVFgqrh+ufez04TFrLxy5VG0T5RpqCA49gEadlmFJIeo2wXCu8O QBwNsd6y7QDPXoKw1m2MbkcBiA== X-Google-Smtp-Source: APXvYqyrHYUpnJutUwuEdjIcnTaEjf81qGqZ/pbR79liSp0465yfzLDAKbhxB++e5Nx7MyuLASXnKw== X-Received: by 2002:a1c:9dc8:: with SMTP id g191mr26249448wme.132.1555400831951; Tue, 16 Apr 2019 00:47:11 -0700 (PDT) Received: from cb-macbook.local (cpc1-cmbg19-2-0-cust104.5-4.cable.virginm.net. [82.27.180.105]) by smtp.gmail.com with ESMTPSA id o17sm64978525wrw.73.2019.04.16.00.47.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 00:47:11 -0700 (PDT) References: <1555106392-20117-1-git-send-email-jiong.wang@netronome.com> <1555106392-20117-9-git-send-email-jiong.wang@netronome.com> <1555321893.44its0xa9r.naveen@linux.ibm.com> <1555322953.xj35xt2bjs.naveen@linux.ibm.com> <874l6zfr4f.fsf@netronome.com> <1555352013.198bf870q9.naveen@linux.ibm.com> <51F46782-5453-4A5F-A4E4-F53DBF4712AD@netronome.com> <1555396526.uk89zrw6ri.naveen@linux.ibm.com> User-agent: mu4e 1.0; emacs 26.1 From: Jiong Wang To: "Naveen N. Rao" Cc: Jiong Wang , alexei.starovoitov@gmail.com, bpf@vger.kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, oss-drivers@netronome.com Subject: Re: [oss-drivers] Re: [PATCH v3 bpf-next 08/19] bpf: insert explicit zero extension insn when hardware doesn't do it implicitly In-reply-to: <1555396526.uk89zrw6ri.naveen@linux.ibm.com> Date: Tue, 16 Apr 2019 08:47:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Naveen N. Rao writes: > Jiong Wang wrote: >> >>> On 15 Apr 2019, at 19:21, Naveen N. Rao wrote: >>> >>> Jiong Wang wrote: >>>> It will be great if you could test the latest set on PowerPC to see if >>>> there is any regression for example for those under test_progs and >>>> test_verifier. >>> >>> With test_bpf, I am seeing a few failures with this patchset. >>> >>>> And it will be even greater if you also use latest llvm snapshot for t= he >>>> testing, which then will enable test_progs_32 etc. >>> >>> Is a newer llvm a dependency? Or, is this also expected to work with ol= der llvm levels? >> >> There is no newer LLVM dependency. This set should work with older >> llvm. >> It is just newer LLVM has better sub-register code-gen support that >> could the generate bpf program contains more elimination >> opportunities for verifier. > > Ok, I will try and get to that by next week (busy with other things > right now). Great, thanks! >>> >>> The set of tests that are failing are listed further below. I looked in= to MUL_X2 and it looks like zero extension for the two initial ALU32 loads = (-1) are being removed, resulting in the failure. >>> >>> I didn't get to look into this in detail -- am I missing something? >> >> Hmm, I guess the issue is: >> = 1. test_bpf.c >> is a testsuite running inside kernel space, it is calling some >> kernel eBPF jit interface directly without calling verifier first, = so this >> set actually hasn=E2=80=99t been triggered. > > Ah, indeed. > >> >> 2. However, the elimination information at the moment is passed from v= erifier >> to JIT backend through >> >> fp->aux->no_verifier_zext >> >> =E2=80=9Cno_verifier_zext=E2=80=9D is initially false, and once ver= ifier inserted zero >> extension, it will be set to true. >> >> Now, for test_bpf, because it doesn=E2=80=99t go through verifier a= t all, so >> =E2=80=9Cno_verifier_zext=E2=80=9D is left at default value which i= s false, meaning >> verifier has inserted zero-extension, so PPC backend then thinks it= is >> safe to eliminate zero-extension by himself. >> >> Perhaps should change =E2=80=9Cno_verifier_zext=E2=80=9D to =E2=80= =9Cverifier_zext=E2=80=9D, then default >> is false and will only be true when verifier really has inserted ze= xt. > > Yes, that's probably better. > >> Was thinking, this will cause JIT backend writing the >> check like >> if (no_verifier_zext) >> insert_zext_by_JIT >> is better than: >> if (!verifier_zext) >> insert_zext_by_JIT >> >> BTW, does test_progs and test_verifier has a full pass on PowerPC? >> On arch without hardware zext like PowerPC, verifier will insert zext an= d test >> mode will still randomisation high 32-bit for those sub-registers not ze= xt, >> this is very stressful test. > > test_verfier is throwing up one failure with this patchset: > #569/p ld_abs: vlan + abs, test 1 FAIL > Failed to load prog 'Success'! > insn 2463 cannot be patched due to 16-bit range > verification time 172602 usec > stack depth 0 > processed 30728 insns (limit 1000000) max_states_per_insn 1 total_states = 1022 peak_states 1022 mark_read 1 > > This test passes with bpf-next/master. Btw, I tried with your v4 > patches though I am replying here... ld_abs: vlan + abs is a special test which calls a helper "bpf_fill_ld_abs_vlan_push_pop" to fill (1 << 15) insns which it the jump distance maximum. Extra code insertion may overflow some jump inside the test. The selftest patch in this set changed the one place to ALU64 to avoid high 32-bit randomization sequence insertion. Now for PowerPC, zero-extension for low 32-bit could be inserted, so this testcase needs further adjustment. I will try to emulate and fix this issue on my x86_64 env. > test_progs has no regression, but has 15 failures even without these > patches that I need to look into. That's a good news to hear no regression on test_progs. Thanks. Regards, Jiong