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]

Message-ID: <ffc58838-c306-49f3-a90a-95b2cf02ae3d@linaro.org>
Date:   Wed, 13 Sep 2023 10:31:49 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Mike Tipton <quic_mdtipton@...cinc.com>
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 13.09.2023 03:29, Mike Tipton wrote:
> 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.
I'm not sure how client drivers would then choose the
correct path other than

switch (soc) {
case 8450:
	tag = QCOM_ICC_TAG_VOTER_8450_HLOS;
	break;
case 8550:
	tag = QCOM_ICC_TAG_VOTER_8550_HLOS;
	break;
...
}

which would be unacceptable.

 
> 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.
Happy to hear that!

Konrad