[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Dec 2019 14:46:33 +0000
From: Mark Rutland <mark.rutland@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
linux-kernel@...r.kernel.org, kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH] arm64: Introduce ISAR6 CPU ID register
On Thu, Dec 12, 2019 at 03:44:23PM +0530, Anshuman Khandual wrote:
> +#define ID_ISAR6_JSCVT_SHIFT 0
> +#define ID_ISAR6_DP_SHIFT 4
> +#define ID_ISAR6_FHM_SHIFT 8
> +#define ID_ISAR6_SB_SHIFT 12
> +#define ID_ISAR6_SPECRES_SHIFT 16
> +#define ID_ISAR6_BF16_SHIFT 20
> +#define ID_ISAR6_I8MM_SHIFT 24
> @@ -399,6 +399,7 @@ static const struct __ftr_reg_entry {
> ARM64_FTR_REG(SYS_ID_ISAR4_EL1, ftr_generic_32bits),
> ARM64_FTR_REG(SYS_ID_ISAR5_EL1, ftr_id_isar5),
> ARM64_FTR_REG(SYS_ID_MMFR4_EL1, ftr_id_mmfr4),
> + ARM64_FTR_REG(SYS_ID_ISAR6_EL1, ftr_generic_32bits),
Using ftr_generic_32bits exposes the lowest-common-denominator for all
4-bit fields in the register, and I don't think that's the right thing
to do here, because:
* We have no idea what ID_ISAR6 bits [31:28] may mean in future.
* AFAICT, the instructions described by ID_ISAR6.SPECRES (from the
ARMv8.0-PredInv extension) operate on the local PE and are not
broadcast. To make those work as a guest expects, the host will need
to do additional things (e.g. to preserve that illusion when a vCPU is
migrated from one pCPU to another and back).
Given that, think we should add an explicit ftr_id_isar6 which only
exposes the fields that we're certain are safe to expose to a guest
(i.e. without SPECRES).
Thanks,
Mark.
Powered by blists - more mailing lists