linux-kernel - Re: [PATCH 2/2] KVM: arm64: Remove use of ARM64_FEATURE

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:   Thu, 22 Dec 2022 12:23:49 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
        kvmarm@...ts.cs.columbia.edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: Remove use of ARM64_FEATURE_MASK()

On Wed, 21 Dec 2022 18:06:10 +0000,
Mark Brown <broonie@...nel.org> wrote:
> 
> The KVM code makes extensive use of ARM64_FEATURE_MASK() to generate a
> mask for fields in the ID registers. This macro has the assumption that
> all feature fields are 4 bits wide but the architecture has evolved to
> add fields with other widths, such as the 1 bit fields in ID_AA64SMFR0_EL1,
> so we need to adjust the
> 
> We could fix this by making ARM64_FEATURE_MASK() use the generated macros
> that we have now but since one of these is a direct _MASK constant the
> result is something that's more verbose and less direct than just updating
> the users to directly use the generated mask macros, writing
> 
> 	#define ARM64_FEATURE_MASK(x)	(x##_MASK)
> 
> obviously looks redundant and if we look at the users updating them turns
> 
> 	val &= ~ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_CSV3);
> 
> into the more direct
> 
> 	val &= ~ID_AA64PFR0_EL1_CSV3_MASK;

If the two are strictly equivalent, then let's use the former as it
results in a tiny diff.

Constantly repainting these files causes no end of conflicts when
rebasing large series (pKVM, NV...), and makes backporting of fixes
much harder than it should be. Specially considering that there is a
single occcurence of an ID register with non-4bit fields.

Just put a FIXME in the various files so that people do the repainting
as they change this code.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.