linux-kernel - Re: [PATCH 1/2] KVM: arm64: Replace custom macros with fields from ID_AA64PFR0

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] [day] [month] [year] [list]

Date: Mon, 13 May 2024 10:58:53 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Mark Rutland <mark.rutland@....com>
Cc: Marc Zyngier <maz@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 catalin.marinas@....com, Oliver Upton <oliver.upton@...ux.dev>,
 Will Deacon <will@...nel.org>, kvmarm@...ts.linux.dev,
 linux-kernel@...r.kernel.org, Fuad Tabba <tabba@...gle.com>
Subject: Re: [PATCH 1/2] KVM: arm64: Replace custom macros with fields from
 ID_AA64PFR0_EL1



On 5/10/24 23:39, Mark Rutland wrote:
> On Mon, Apr 29, 2024 at 07:53:14AM +0530, Anshuman Khandual wrote:
>> On 4/18/24 13:09, Marc Zyngier wrote:
>>> On Thu, 18 Apr 2024 06:38:03 +0100,
>>> Anshuman Khandual <anshuman.khandual@....com> wrote:
>>>>  #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_EL0_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_EL1_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_EL2_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_EL3_IMP) | \
>>>
>>> If you are going to rework this, can we instead use something less
>>> verbose such as SYS_FIELD_GET()?
>>
>> Just wondering, is not FIELD_PREP() and SYS_FIELD_GET() does the exact opposite thing.
>> The earlier builds the entire register value from various constituents, where as the
>> later extracts a single register field from a complete register value instead. Or did
>> I just misunderstood something here.
>  
> He means use one of the SYS_FIELD_*() helpers, e.g. SYS_FIELD_PREP_ENUM(), with
> which this can be:
> 
> #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL0, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL1, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL2, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL3, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, RAS, IMP) \
>         )
> 
> ... which is far less verbose, and much easier to read.

Got it, this makes sense, will fold in the above changes and respin
after the merge window. Thanks for the clarification.