linux-kernel - Re: [PATCH 00/53] icc-rpmh multi-RSC voting groundwork

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Sep 2023 18:29:51 -0700
From:   Mike Tipton <quic_mdtipton@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
CC:     Georgi Djakov <djakov@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        <cros-qcom-dts-watchers@...omium.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-pm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/53] icc-rpmh multi-RSC voting groundwork

On Wed, Sep 06, 2023 at 02:14:14PM +0200, Konrad Dybcio wrote:
> > The general idea is that we could use tags for this. So, instead of...
> > 
> >   path = icc_get(dev, MASTER_MDP_DISP, SLAVE_EBI1_DISP);
> > 
> > it would be...
> > 
> >   path = icc_get(dev, MASTER_MDP, SLAVE_EBI1);
> >   icc_set_tag(path, QCOM_ICC_TAG_VOTER_DISP);
> > 
> > I have an early prototype with basic testing already. I can hopefully
> > clean it up and post for review in the next couple of weeks.
> I was initially not very happy with this approach (overloading tags
> with additional information), but it grew on me over time.
> 
> My only concern is that if we reserve say bits 16-31 for path tags
> (remember, dt-bindings are ABI), we may eventually run out of them.

The voter tags wouldn't require bitmasks like the bucket tags do. We'd
just need an integer for each voter shifted into the proper position in
the tag value. Thus, reserving N bits for the voters would give us 2**N
voters, which should be plenty. For example:

  #define QCOM_ICC_VOTERS_START           16
  #define QCOM_ICC_VOTERS_END             23

  #define QCOM_ICC_TAG_VOTER_HLOS         (0 << QCOM_ICC_VOTERS_START)
  #define QCOM_ICC_TAG_VOTER_DISP         (1 << QCOM_ICC_VOTERS_START)
  #define QCOM_ICC_TAG_VOTER_CAM_IFE_0    (2 << QCOM_ICC_VOTERS_START)
  #define QCOM_ICC_TAG_VOTER_CAM_IFE_1    (3 << QCOM_ICC_VOTERS_START)
  #define QCOM_ICC_TAG_VOTER_CAM_IFE_2    (4 << QCOM_ICC_VOTERS_START)

The applicable voters should likely be defined in the target-specific
headers, rather than the common qcom,icc.h. The bit range used for them
could be common, but each target may only support a small subset of the
total set of possible voters across all targets.

Clients requiring multiple voters for the same logical path should be
rare. On the off-chance they require that, they could just request the
same path multiple times with different voter tags applied and call
icc_set_bw() for each of them separately.

I'm back from travel and vacation and plan to pick this up again soon.