Message ID | 20241202172134.384923-1-maz@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | KVM: arm64: Add NV timer support | expand |
On Mon, Dec 02, 2024 at 05:21:23PM +0000, Marc Zyngier wrote: > Here's another batch of NV-related patches, this time bringing in most > of the timer support for EL2 as well as nested guests. > > The code is pretty convoluted for a bunch of reasons: > > - FEAT_NV2 breaks the timer semantics by redirecting HW controls to > memory, meaning that a guest could setup a timer and never see it > firing until the next exit > > - We go try hard to reflect the timer state in memory, but that's not > great. > > - With FEAT_ECV, we can finally correctly emulate the virtual timer, > but this emulation is pretty costly > > - As a way to make things suck less, we handle timer reads as early as > possible, and only defer writes to the normal trap handling > > - Finally, some implementations are badly broken, and require some > hand-holding, irrespective of NV support. So we try and reuse the NV > infrastructure to make them usable. This could be further optimised, > but I'm running out of patience for this sort of HW. > > What this is not implementing is support for CNTPOFF_EL2. It appears > that the architecture doesn't let you correctly emulate it, so I guess > this will be trap/emulate for the foreseeable future. > > This series is on top of v6.13-rc1, and has been tested on my usual M2 > setup, but also on a Snapdragon X1 Elite devkit. I would like to thank > Qualcomm for the free hardware with no strings (nor support) attached! This series is looking pretty good to me, but I think it'd be good to remap "EL0 timer" -> "EL1 timer" throughout this series to match the architectural term.
Hi Marc, On Mon, 2 Dec 2024 17:21:23 +0000, Marc Zyngier <maz@kernel.org> wrote: > Here's another batch of NV-related patches, this time bringing in most > of the timer support for EL2 as well as nested guests. > > The code is pretty convoluted for a bunch of reasons: > > - FEAT_NV2 breaks the timer semantics by redirecting HW controls to > memory, meaning that a guest could setup a timer and never see it > firing until the next exit > > - We go try hard to reflect the timer state in memory, but that's not > great. > > - With FEAT_ECV, we can finally correctly emulate the virtual timer, > but this emulation is pretty costly > > - As a way to make things suck less, we handle timer reads as early as > possible, and only defer writes to the normal trap handling > > - Finally, some implementations are badly broken, and require some > hand-holding, irrespective of NV support. So we try and reuse the NV > infrastructure to make them usable. This could be further optimised, > but I'm running out of patience for this sort of HW. > > What this is not implementing is support for CNTPOFF_EL2. It appears > that the architecture doesn't let you correctly emulate it, so I guess > this will be trap/emulate for the foreseeable future. > > This series is on top of v6.13-rc1, and has been tested on my usual M2 > setup, but also on a Snapdragon X1 Elite devkit. I would like to thank > Qualcomm for the free hardware with no strings (nor support) attached! > > If you are feeling brave, you can run the whole thing from [1]. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-next > I was feeling brave, and I think I see an issue in the cpufeature change in the kvm-arm64/nv-e2h-select branch that's a part of kvm-arm64/nv-next. In d75a4820a897 ("arm64: cpufeature: Handle NV_frac as a synonym of NV2"), I don't see NV_frac being added to the FTR bits. I believe that means it will get sanitized out and consequently not seen by the NV feature detection code. Does that commit also need: diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 9fa8bd77ae0..f97459e160b 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -480,6 +480,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = { static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = { S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0), + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0), ARM64_FTR_END, }; Thanks, Chase
Hi Chase, On Mon, 09 Dec 2024 14:24:29 +0000, Chase Conklin <chase.conklin@arm.com> wrote: > > Hi Marc, > > On Mon, 2 Dec 2024 17:21:23 +0000, Marc Zyngier <maz@kernel.org> > wrote: > > > If you are feeling brave, you can run the whole thing from [1]. > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-next > > > > I was feeling brave, and I think I see an issue in the cpufeature change > in the kvm-arm64/nv-e2h-select branch that's a part of > kvm-arm64/nv-next. In d75a4820a897 ("arm64: cpufeature: Handle NV_frac as a synonym of NV2"), > I don't see NV_frac being added to the FTR bits. I believe that means it > will get sanitized out and consequently not seen by the NV feature > detection code. Does that commit also need: > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 9fa8bd77ae0..f97459e160b 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -480,6 +480,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = { > > static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = { > S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0), > + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0), > ARM64_FTR_END, > }; Ah, I always get tripped by that one. You are absolutely correct, this is needed. I'll fold that in. Thanks again, M.