From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67])
 by mx.groups.io with SMTP id smtpd.web10.1003.1582669650358201428
 for <devel@edk2.groups.io>;
 Tue, 25 Feb 2020 14:27:30 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@linaro.org header.s=google header.b=pWqMB0c4;
 spf=pass (domain: linaro.org, ip: 209.85.221.67, mailfrom: ard.biesheuvel@linaro.org)
Received: by mail-wr1-f67.google.com with SMTP id z3so609880wru.3
        for <devel@edk2.groups.io>; Tue, 25 Feb 2020 14:27:30 -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=cVdznvqefbtFHRQ1CzjhX1jIOVAicDhn7t44hO40pzc=;
        b=pWqMB0c4zBgjTEYVkfJNBDcfD30cR5sjt0wmUy0ma4eWR1gAyIioJ7hBBCzaydjOct
         B0ZJy84ugY0RGSdSpyY7Y7LdcSS1ySKYamfIG/GWxruzRg0qSLd335DRSRYUpXtW6KcS
         bhmgXx3RejZXlzhjsNbBzIqpz93SbsipGGkf1VKorvwEqajtbL7pnIwWaWwWCmOevnXq
         6m/zE4CpMuTLScRR6+sFbQ5yFyLU+kZDHt6VPFW2clMmLNF2konl4l9DaWKVPERG5laQ
         XtMLVD4mANnHr4GyRcVV9ie4wk+66khAI5NSq1kaVmgUe+0o28Ik9OprwupNA8zGgrx/
         TXyw==
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=cVdznvqefbtFHRQ1CzjhX1jIOVAicDhn7t44hO40pzc=;
        b=J+eN+7k7F045enasyDDhao86+EyT/NAU+A8t9uxDc0mq/vc3lw3C+4ml2I/rUWmIuB
         v9oGWrCrmGAAjt3crvFCz2gm1wGgCNtQK5v4ac22u65RiVHtCqHKrP5EUvix6y4KG7Y5
         XTrEMI3VDX22+tWdC/uEwmfOZp2xv0xsBhFN2QzxFqYh79F9lbsl9EynitveR51VRsZO
         Cc7I4oHDBfaEJohS9XfLQ5yu22Ei8N+4QtD8g8Jfe7Iom2XYv2fuilZAVCkvI0+EYIaV
         k8SaVni+1XgVqcl5cjXDsWlXbUvlEuwtYfs2JlhGmLROchiVZW7xkNjZDwR+23mN+sn0
         Gh/g==
X-Gm-Message-State: APjAAAUiI+u77xgWCXlRCrg13MsertTVAzJVo8PabvZZLEKNSYxghGzA
	RAn/Uj/Uu+mswOij2bd+PfDiicfdrbRWaMGZbfi+5T3hFQw=
X-Google-Smtp-Source: APXvYqzI6mzAZg4NCFijLo/dJccDYsM1d8DD04PUlJ0GUqEoGznoauQaQ9CdMPA2l+Av/SB5sRJmD96EEiOiJePgyoY=
X-Received: by 2002:a05:6000:110b:: with SMTP id z11mr1318319wrw.252.1582669648493;
 Tue, 25 Feb 2020 14:27:28 -0800 (PST)
MIME-Version: 1.0
References: <20200225182834.19380-1-ard.biesheuvel@linaro.org> <CAKv+Gu_9nH40LMvHMqBGoxV9aB8wLKyOivKOUXvFpFbkyXGoEA@mail.gmail.com>
In-Reply-To: <CAKv+Gu_9nH40LMvHMqBGoxV9aB8wLKyOivKOUXvFpFbkyXGoEA@mail.gmail.com>
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
Date: Tue, 25 Feb 2020 23:27:17 +0100
Message-ID: <CAKv+Gu_KAAW1s+gtytJ9ROHo+L=Vr5X7OtCsFkW1edtK_P+xrA@mail.gmail.com>
Subject: Re: [PATCH 1/1] ArmPlatformPkg/PrePi: replace set/way cache ops with by-VA ones
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Leif Lindholm <leif@nuviainc.com>, Laszlo Ersek <lersek@redhat.com>, Pete Batard <pete@akeo.ie>
Content-Type: text/plain; charset="UTF-8"

On Tue, 25 Feb 2020 at 19:31, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel <ard.biesheuvel@linaro.org> 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 <ard.biesheuvel@linaro.org>
> > ---
>
> 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?