From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by mx.groups.io with SMTP id smtpd.web09.4515.1582700241977830563 for ; Tue, 25 Feb 2020 22:57:22 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=R6vPrmrw; spf=pass (domain: linaro.org, ip: 209.85.128.67, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f67.google.com with SMTP id m3so1771790wmi.0 for ; Tue, 25 Feb 2020 22:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqJQuNBV9r4LsSutQtg/Puh7Z9oH6LV1kxBVAGyfix8=; b=R6vPrmrwF3Hsw58IpSYvcrwpq1P3sAVh4nrYc1xO1/p04/bMHdVXAT+JKJiNEeC9YS sc5yZFwA5sDNgglzhPNt1qUJsoH/J1ygficDap2CB0at2l11ugdFNx2MR2brwdLTmzPE c9DUA9P3WVww6AL1H0pW62W5JsRmAHKB15E+BteJYlZ+Z9XuUJ6mWRHBzwR9OMq3TSdu pVi1pgoVlvYaHTJsL4Uw1hfOhI7GcNtDiBybL41V+n5snSjeifx0lV0ylR+Vw09lZRbF 3/c9PsXIrEqkuttGqdq51WZp9pMRielQkMFg0hy1gu0Ul/CCsyuhTetG213DgZrxoMH4 5b2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XqJQuNBV9r4LsSutQtg/Puh7Z9oH6LV1kxBVAGyfix8=; b=ZSVI0FlxAJUOdRfiF20PljFPpHvEJkQlDi58nmW4ZQN0Qq7pH5P2AiDMA3eEVSmt4C 5MlKF+5T0h/dwOxUA9L06HQuHjEN+D/nsOjWwDtlRvnZQE1wdEw+M1OdV308xMFPU24t SEw3FtvwouPvWUUV6akm2cvssPtvporHHvSdPm14Ce44gCnoR+/AxEi6dulBtMDJ/oQv cqiB6RDLcEMiABFsu6GzruH2X4szNdSq2F0XsKn17OsET1y5uBouQj69nHKE4NabLD7l yPpbuoAYeOGEk42fkGLUjJWLTpMabxlTJj18IkdVc5KOhk85UZ0i9iOmlnB4V/1CcKA7 RBXA== X-Gm-Message-State: APjAAAXcN74xeTwuIaeTzGRuzfsx/wsamsJjWazG8+m8Fq686LEPr2JV 60DRje3r8d40LgHhcK1JQXYY4WiOeA3/alkKKAT5uA== X-Google-Smtp-Source: APXvYqzMcHt40+QZXDAMDrhR3njY3JwNvr/n62ZeshNFQ0p/zoul0htJJT1BVvZRI8yMJFnF29/XHxBj2YM4xg8SbAI= X-Received: by 2002:a7b:c4cc:: with SMTP id g12mr3880336wmk.68.1582700240405; Tue, 25 Feb 2020 22:57:20 -0800 (PST) MIME-Version: 1.0 References: <20200225182834.19380-1-ard.biesheuvel@linaro.org> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 26 Feb 2020 07:57:09 +0100 Message-ID: Subject: Re: [PATCH 1/1] ArmPlatformPkg/PrePi: replace set/way cache ops with by-VA ones To: Pete Batard Cc: edk2-devel-groups-io , Leif Lindholm , Laszlo Ersek Content-Type: text/plain; charset="UTF-8" On Wed, 26 Feb 2020 at 02:34, Pete Batard wrote: > > Hi Ard, > > On 2020.02.25 22:27, Ard Biesheuvel wrote: > > On Tue, 25 Feb 2020 at 19:31, Ard Biesheuvel wrote: > >> > >> On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel wrote: > >>> > >>> Cache maintenance operations by set/way are only intended to be used > >>> in the context of on/offlining a core, while it has been taken out of > >>> the coherency domain. Any use intended to ensure that the contents of > >>> the cache have made it to main memory is unreliable, since cacheline > >>> migration and non-architected system caches may cause these contents > >>> to linger elsewhere, without being visible in main memory once the > >>> MMU and caches are disabled. > >>> > >>> In KVM on Linux, there are horrid hacks in place to ensure that such > >>> set/way operations are trapped, and replaced with a single by-VA > >>> clean/invalidate of the entire guest VA space once the MMU state > >>> changes, which can be costly, and is unnecessary if we manage the > >>> caches a bit more carefully, and perform maintenance by virtual > >>> address only. > >>> > >>> So let's get rid of the call to ArmInvalidateDataCache () in the > >>> PrePeiCore startup code, and instead, invalidate the UEFI memory > >>> region by virtual address, which is the only memory region we will > >>> be touching with the caches and MMU both disabled and enabled. > >>> (This will lead to data corruption if data written with the MMU off > >>> is shadowed by clean, stale cachelines that stick around when the > >>> MMU is enabled again.) > >>> > >>> Signed-off-by: Ard Biesheuvel > >>> --- > >> > >> Forgot to add a note that this is the *PrePi* version, not the > >> PrePeiCore one that I sent before. > >> > >> @Pete: this might affect RPi3 and RPi4, and I am currently not able to > >> test it. If it's not too much trouble, I'd appreciate a Tested-by. If > >> not, I'll test it myself, but it may take me a while to get around to > >> it. > >> > > > > Actually, I decided to dedicate some of my evening to have a go at this myself. > > > > This patch works for me on RPi4, as well as the BCM GENET with the > > latest changes, and the version of the driver that turned up in > > net-next today > > > > I am getting around 100 - 150 Mbit/s - is that what I should expect? > > Not sure what device you're running your system from, because I'm easily > reaching 700 Mbit/s when running a large Samba copy from a USB 3.0 > drive, which I hope should work well enough as a stress test. > > Tested both for read and write, with and without the patch (but only on > Pi 4). No noticeable reduction in speed as far as I can tell. > > With this: > > Tested-By: Pete Batard > Thanks Pete. I realize I implied by my answer that this patch might have any effect on the GENET performance, but these are unrelated. I just meant to say that this is the first time I unboxed the RPi4 since early December, to test this patch, but also, to test GENET myself in ACPI mode for the first time (or at all, for that matter) This patch [if done wrong] would cause boot issue very early on, which it apparently doesn't, so yay! Thanks, Ard.