From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66])
 by mx.groups.io with SMTP id smtpd.web10.10247.1583323503642415143
 for <devel@edk2.groups.io>;
 Wed, 04 Mar 2020 04:05:04 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@linaro.org header.s=google header.b=PBt1HOix;
 spf=pass (domain: linaro.org, ip: 209.85.221.66, mailfrom: ard.biesheuvel@linaro.org)
Received: by mail-wr1-f66.google.com with SMTP id t11so2081530wrw.5
        for <devel@edk2.groups.io>; Wed, 04 Mar 2020 04:05:03 -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=hc0mJH7FXyvDaA+r8WexolmgbPnbE/2fPr/cykx2sX8=;
        b=PBt1HOixOKIk/GU7yP6MJyAMgju98Slqt6EGwRl59ZtiOrMKLYjKP61ds3TulTvNK1
         2SGja0TejqTBAO+pfOHhr6LGciAsJst857Ek0roxesoz2HDDON9wdvwjGeoPVAjsp+8l
         O/3136ddZkcfsl2S2aocAxKdc5McxV+d1+4X/i1c1vhtqtrMQMlcnHtYjObByaaN6VwI
         0BEyvYcVoxgp3HOnWI7hp9Lzj3P+JkF0hLBkqq3Fd7a5pnjKFYQdfoocf+QbEZTMVbbr
         qjzCvUQkXQBay28uxO2YKwHZQCCwBhZdZG6WnUh9pxmrYRh4JpAcnj4RiN9UteNXzr5W
         PrkQ==
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=hc0mJH7FXyvDaA+r8WexolmgbPnbE/2fPr/cykx2sX8=;
        b=QZ7KWIiZ4c1GBWVMzUZoz9Fd6aGzNMcrCttAtm5lnwyEwsg1jRdkvfB3uENbEB6cdv
         P+v3E5ACe2E4YOQfzyPhcvhf6v6tdA2VW5Qy1S7ZJrbVWyM2Kujegk/1cxKTRKM+fMAG
         0mRzgJ5Q6+AfWiMvUdot3+u5PZRcjvRwHez3gxMA2X0ejYquqtixVwzy4+Fwl0XvKhea
         vNk/eEC//NZObL2GY+b8MrYmlrBHj83aQ1qc0runUKNNvKI+72n0FXvtWoD5Sf4P/cmY
         IF9BqkCdCDBCTy90HIy8Gx3QhC8Qc6jz5slUuOwiMdCZ9A5haOXrhl2hepjkxh5jnpqU
         xS6Q==
X-Gm-Message-State: ANhLgQ0fMCdY37xqrA1PSF7ceVK313SO1h1HEO1HQ5N3KV7MJYUJpD1P
	Ej8LRFWQrVehZapR6UpDj6xvnmpB9wnG6ddfhCbKqA==
X-Google-Smtp-Source: ADFU+vuOSSOyq5dYowhulve40Kf/15K+HMlOGwtquz6KjcyBv9FbulqiYfs+YWXuNZjNx/aUJQNWS6459901BdX9rpA=
X-Received: by 2002:adf:e742:: with SMTP id c2mr3794684wrn.262.1583323502109;
 Wed, 04 Mar 2020 04:05:02 -0800 (PST)
MIME-Version: 1.0
References: <20200226100353.31962-1-ard.biesheuvel@linaro.org>
 <20200226100353.31962-7-ard.biesheuvel@linaro.org> <20200302131321.GK23627@bivouac.eciton.net>
 <CAKv+Gu875jaa48Bhvb7WP_-BEpVorVCb-56YAhcdp3jAG=maTA@mail.gmail.com>
In-Reply-To: <CAKv+Gu875jaa48Bhvb7WP_-BEpVorVCb-56YAhcdp3jAG=maTA@mail.gmail.com>
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
Date: Wed, 4 Mar 2020 13:04:51 +0100
Message-ID: <CAKv+Gu977om_59kpHjVT-Jw2WWq1=++3=MTRxDUrTO-pcB80=Q@mail.gmail.com>
Subject: Re: [PATCH 6/6] ArmPkg/ArmLib: deprecate set/way cache maintenance routines
To: Leif Lindholm <leif@nuviainc.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>, Laszlo Ersek <lersek@redhat.com>, 
	Sami Mujawar <sami.mujawar@arm.com>
Content-Type: text/plain; charset="UTF-8"

On Mon, 2 Mar 2020 at 14:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Mon, 2 Mar 2020 at 14:13, Leif Lindholm <leif@nuviainc.com> wrote:
> >
> > On Wed, Feb 26, 2020 at 11:03:53 +0100, Ard Biesheuvel wrote:
> > > Cache maintenance on ARMv7 systems and up should be done by virtual
> > > address if the purpose is to manage the cached state of contents of
> > > memory. Set/way operations are only intended to maintain the caches
> > > themselves, e.g., to ensure that the contents of dirty cachelines
> > > are brought to main memory before the core is powered off entirely.
> > >
> > > UEFI on ARM is typically not involved in the latter at all, and any
> > > cache maintenance it does is to ensure that the memory it occupies
> > > and modifies remains in a consistent state with respect to the
> > > caches.
> > >
> > > So let's deprecate the set/way routines now that we have removed all
> > > uses of it in the core code.
> >
> > Does this patch simply get dropped in favour of the ASSERT variant?
> >
>
> Yes.
>
> But I realised that we still need a fix for CmdRunAxf in that case :-(

As discussed on IRC, with CmdRunAxf out of the way, we can ASSERT ()
on any use of the set/way ops with the MMU/dcache enabled. In any
case, this 6/6 will simply be dropped, and superseded by my followup
series '[PATCH 0/3] ArmPkg/ArmLib: ASSERT() on misuse of set/way ops'