| Message ID | 20231127114559.990314-7-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: Add support for FEAT_E2H0, or lack thereof | expand |
On Mon, Nov 27, 2023 at 11:45:52AM +0000, Marc Zyngier wrote: > FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H > can be set to 0. Amusingly, this feature is set to 0 when implemented, > and otherwise negative. > > Add a new capability and detection infrastructure to detect the > absence of FEAT_E2H0. > > Signed-off-by: Marc Zyngier <maz@kernel.org> > --- > arch/arm64/kernel/cpufeature.c | 7 +++++++ > arch/arm64/tools/cpucaps | 1 + > 2 files changed, 8 insertions(+) > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 4a72fb26daec..6ef9811f7bb7 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > .matches = has_cpuid_feature, > ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP) > }, > + { > + .desc = "FEAT_E2H0 not implemented", > + .capability = ARM64_HCR_E2H_RES1, > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, Is ARM64_CPUCAP_SYSTEM_FEATURE the right thing to use here? For example, if the boot CPUs have this feature but a late CPU doesn't, then I think we should be ok as long as we're using VHE, but I don't think the above takes that into account. Maybe we shouldn't be adding new capabilities for this at all, and instead just look at the sanitised register value when we need to? Will
On Mon, 11 Dec 2023 12:42:38 +0000, Will Deacon <will@kernel.org> wrote: > > On Mon, Nov 27, 2023 at 11:45:52AM +0000, Marc Zyngier wrote: > > FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H > > can be set to 0. Amusingly, this feature is set to 0 when implemented, > > and otherwise negative. > > > > Add a new capability and detection infrastructure to detect the > > absence of FEAT_E2H0. > > > > Signed-off-by: Marc Zyngier <maz@kernel.org> > > --- > > arch/arm64/kernel/cpufeature.c | 7 +++++++ > > arch/arm64/tools/cpucaps | 1 + > > 2 files changed, 8 insertions(+) > > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 4a72fb26daec..6ef9811f7bb7 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > > .matches = has_cpuid_feature, > > ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP) > > }, > > + { > > + .desc = "FEAT_E2H0 not implemented", > > + .capability = ARM64_HCR_E2H_RES1, > > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > Is ARM64_CPUCAP_SYSTEM_FEATURE the right thing to use here? For example, > if the boot CPUs have this feature but a late CPU doesn't, then I think > we should be ok as long as we're using VHE, but I don't think the above > takes that into account. > > Maybe we shouldn't be adding new capabilities for this at all, and instead > just look at the sanitised register value when we need to? That's probably good enough for this particular use of E2H0, as this is not used on any fast path. However, when E2H0 is 0b1110 (NV1 being RES0, and thus the guest's own HCR_EL2.E2H being RES1), we need to sanitise the guest's HCR_EL2 no matter what the guest writes there. With that in mind, __vcpu_el2_e2h_is_set() using the sanitised value would result in a binary search on a lot of very hot paths, something that I'm keen to avoid. So while I'm happy to drop this particular cap, I'll keep the one introduced in patch #6. Thanks, M.
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 4a72fb26daec..6ef9811f7bb7 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .matches = has_cpuid_feature, ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP) }, + { + .desc = "FEAT_E2H0 not implemented", + .capability = ARM64_HCR_E2H_RES1, + .type = ARM64_CPUCAP_SYSTEM_FEATURE, + .matches = has_cpuid_feature, + ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI) + }, {}, }; diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps index b98c38288a9d..8866ea9bf995 100644 --- a/arch/arm64/tools/cpucaps +++ b/arch/arm64/tools/cpucaps @@ -52,6 +52,7 @@ HAS_TIDCP1 HAS_TLB_RANGE HAS_VIRT_HOST_EXTN HAS_WFXT +HCR_E2H_RES1 HW_DBM KVM_HVHE KVM_PROTECTED_MODE
FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H can be set to 0. Amusingly, this feature is set to 0 when implemented, and otherwise negative. Add a new capability and detection infrastructure to detect the absence of FEAT_E2H0. Signed-off-by: Marc Zyngier <maz@kernel.org> --- arch/arm64/kernel/cpufeature.c | 7 +++++++ arch/arm64/tools/cpucaps | 1 + 2 files changed, 8 insertions(+)