Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3707660pxj; Mon, 21 Jun 2021 04:56:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJ6OCYqvlMnsXLMxT4sKaZrHhUtb1h6D/1pprGbtwTqOmd79YcliAaWSkEWBaERC1yqiu4 X-Received: by 2002:a17:907:98c4:: with SMTP id kd4mr3213690ejc.119.1624276615628; Mon, 21 Jun 2021 04:56:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624276615; cv=none; d=google.com; s=arc-20160816; b=zSKxP/5BnFWx4PHmQTkuhCsAAmv+u+an4Y16Qf19tuWYeKrJ4dBEIW1a343Ufu9HOS gEPJcg509JVPQikaALFpDDdw3wPJJqm2oZp3vgTeqsCpERwW0LXL812L2yfHDyIUTkjk VII1rAqZWTeNUMLbs0nS49SuA/X3ehAeSt9Zm4jNf9KwiT5Siy+LdU8DLwv1Y7dM7stx M7XTux34CdES65zsvZ0Zc8CRZnlMXp4R1Xci0FMWCJtlaURxsWpvuyuiQcZu3OVhf9h9 ec0BXus8LwdFYn24vfTtOY0H+mPpkoSKbTZWZSFlGxEB/7z93yp1pvxI4US1k+EWZbtP 3T8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=+Jis+uKW0ybLBNM+xkbKO/vcEH9p86k5XrgOwkjbpfo=; b=Em0MNRZY2a1zoYbTBLSw1+8JeW1AGUQdu8lHyVUG+eBRigYzozBR0WBbQxrWwcxZ3K XoTo1Eg/mpG0epDmXKDI/z1b3W933UA3JIlU65qQGHRrwOCVAtOuJsE++tPsP3N+w1VB IMdWjfQPHxXs9ym+28En/kQjTrLRFKjMO9Wt/srKckvlLBCGaeBikaJGBlXq4Rxr73JR mxr59BU3w/G0qdgnsu/zYyaJ9eKbtv2EWRWarMqx0sRxmepzmadjuQcmc//a52lmx8Od OA+RO3x0KDRkyyR6fVg1Z453N9BXhA6xJO0gnSItRdtetpZPr7SQe5PkkfKba+G6SV6c ZuJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz1si10094132ejc.257.2021.06.21.04.56.32; Mon, 21 Jun 2021 04:56:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229710AbhFUL5o (ORCPT + 99 others); Mon, 21 Jun 2021 07:57:44 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:54957 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhFUL5n (ORCPT ); Mon, 21 Jun 2021 07:57:43 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MC2o9-1m7cr70jAD-00CUOX; Mon, 21 Jun 2021 13:55:28 +0200 Received: by mail-wm1-f50.google.com with SMTP id p10-20020a05600c430ab02901df57d735f7so1532904wme.3; Mon, 21 Jun 2021 04:55:28 -0700 (PDT) X-Gm-Message-State: AOAM532FMSGGgyOOKbSNXYo3PW1K6IZ3xtgsow1fiDbsm6ti0m+7Xpia zMkvTS6IhlQyRDj0mF+Ix7MB4lAQwgu+aqfL/hc= X-Received: by 2002:a1c:c90f:: with SMTP id f15mr26864111wmb.142.1624276527837; Mon, 21 Jun 2021 04:55:27 -0700 (PDT) MIME-Version: 1.0 References: <202104031853.vDT0Qjqj-lkp@intel.com> <1624232938.d90brlmh3p.astroid@bobo.none> <87im273604.fsf@mpe.ellerman.id.au> In-Reply-To: <87im273604.fsf@mpe.ellerman.id.au> From: Arnd Bergmann Date: Mon, 21 Jun 2021 13:53:10 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: arch/powerpc/kvm/book3s_hv_nested.c:264:6: error: stack frame size of 2304 bytes in function 'kvmhv_enter_nested_guest' To: Michael Ellerman Cc: Nathan Chancellor , Nicholas Piggin , kernel test robot , Andrew Morton , clang-built-linux , kbuild-all@lists.01.org, Kees Cook , Linux Kernel Mailing List , Linux Memory Management List , linuxppc-dev , kvm-ppc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Y+mfW4xhH5X8RHYe/AsstC3IpSynQFWAwEXO8InZjsrHQZW/2b+ 1UBV4MoB+URF2gxOJlrS+s7s9NmurjL0uik9e/uCqns1W+izKReAmE9+e0gcZ/v0gPfwFos HQGd2ZNDi02jfP881HwfccIz0dM1fqw2ngr+DLhjoUVFaQyRX8jwoHurWm3Yzzm1gHwfid1 MC/tdA5pFaFrn4ASUjVMg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:iX2r2V5/dms=:kPoXN4bzb0sO7xYLrvrwtd ZKOC2F5GdbxBziZ5vV4wblLQ3kaQGw8j3jVypvlSLqI2Jhs3O2Gx6MVTT+mCLxiqxMYuwIb2B a+a+vjwrfjBOJDRomOSprQ+Ulv9CjH3bYP6TOKmkoCzsQmMszR53TCH4WjtAcFcRfR9SMVsGI wqGdL8rt/EP1uhASSWXChbDGEnRYFyeGWmlOsWFfgUvZw9lQ1UvXhdh1BbGJtLte7eABX0Uov 0JhRcgi5I7JjQXq8tS8zTjw1683LLuhSEBjSxP5szpXkare/9uSmIL7fjeq2mGmU0zGV3JFuN 8soHN7jmrVmpkq9LULUSBqL7iS50K1FiG4LWBNnWyi8HcluLkhPUz9xO+7F4p/I7zmSDrWcOq NRP+TNlrKAlPvzhWVFDHuacHxLLWlNAMDjUxUJ1W7Yt8rLSw+i6SDCMlwGZwfXCL3Pc/n2pat kL85KhC2LJZDG/TqKDico5sHs0+j6lEwQHjU8v60LfWjPyKC9y6zLjlISJ5JOjEAEJC7X4Jyy CWXFsQHqsJRfIn0/YhXOBqpy8cTv/ALRDRJZ/TAONbMrd7h6F8+4g0AdR9jWSIfF+NCwyiymg 8A6BCtJiriKOQjs/3doVU7bjEPBdmZ7WwYko6hiYvtLBmeVAin/GaLc5vge59T/n6wZPDwTrA pHVE= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 21, 2021 at 11:46 AM Michael Ellerman wrote: > Nathan Chancellor writes: > > On 6/20/2021 4:59 PM, Nicholas Piggin wrote: > >> Excerpts from kernel test robot's message of April 3, 2021 8:47 pm: > >>> > >>> vim +/kvmhv_enter_nested_guest +264 arch/powerpc/kvm/book3s_hv_nested.c > >> > >> Not much changed here recently. It's not that big a concern because it's > >> only called in the KVM ioctl path, not in any deep IO paths or anything, > >> and doesn't recurse. Might be a bit of inlining or stack spilling put it > >> over the edge. > > > > It appears to be the fact that LLVM's PowerPC backend does not emit > > efficient byteswap assembly: > > > > https://github.com/ClangBuiltLinux/linux/issues/1292 > > > > https://bugs.llvm.org/show_bug.cgi?id=49610 > > > >> powerpc does make it an error though, would be good to avoid that so the > >> robot doesn't keep tripping over. > > > > Marking byteswap_pt_regs as 'noinline_for_stack' drastically reduces the > > stack usage. If that is an acceptable solution, I can send it along > > tomorrow. > > Yeah that should be OK. That's fine with me as well. > Can you post the before/after disassembly when > you post the patch? > > It should just be two extra function calls, which shouldn't be enough > overhead to be measurable. The thing I remember is that the 'before' code here is some seriously bad output from llvm, and it would be helpful to have someone get the compiler to emit the correct powerpc byteswap instructions and avoid the excessive stack spilling. The warning here is just a symptom of a missed optimization and the same thing probably happens elsewhere on powerpc, even if it doesn't exceed the stack warning limit. Arnd