On Wed, 20 Sep 2023 20:50:29 +0100,
Oliver Upton <oliver.upton@xxxxxxxxx> wrote:
>
> To date KVM has relied on kvm_reset_vcpu() failing when the vCPU feature
> flags are unsupported by the system. This is a bit messy since
> kvm_reset_vcpu() is called at runtime outside of the KVM_ARM_VCPU_INIT
> ioctl when it is expected to succeed. Further complicating the matter is
> that kvm_reset_vcpu() must tolerate be idemptotent to the config_lock,
> as it isn't consistently called with the lock held.
>
> Prepare to move feature compatibility checks out of kvm_reset_vcpu() with
> a 'generic' check that compares the user-provided flags with a computed
> maximum feature set for the system.
>
> Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx>
> ---
> arch/arm64/kvm/arm.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 4866b3f7b4ea..66f3720cdd3a 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1190,6 +1190,16 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
> return -EINVAL;
> }
>
> +static unsigned long system_supported_vcpu_features(void)
> +{
> + unsigned long features = KVM_VCPU_VALID_FEATURES;
> +
> + if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1))
I think we can now convert this to a cpus_have_final_cap(), as Mark is
getting rid of the helper altogether, see [1].
Thanks,
M.
[1] https://lore.kernel.org/r/20230919092850.1940729-1-mark.rutland@xxxxxxx
--
Without deviation from the norm, progress is not possible.
