On Wed, 2022-08-31 at 00:34 +0000, Sean Christopherson wrote:
> Add a helper to perform the final kick, two instances of the ICR decoding
> is one too many.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> ---
> arch/x86/kvm/svm/avic.c | 25 +++++++++++++------------
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> index 3959d4766911..2095ece70712 100644
> --- a/arch/x86/kvm/svm/avic.c
> +++ b/arch/x86/kvm/svm/avic.c
> @@ -329,6 +329,16 @@ void avic_ring_doorbell(struct kvm_vcpu *vcpu)
> put_cpu();
> }
>
> +
> +static void avic_kick_vcpu(struct kvm_vcpu *vcpu, u32 icrl)
> +{
> + vcpu->arch.apic->irr_pending = true;
> + svm_complete_interrupt_delivery(vcpu,
> + icrl & APIC_MODE_MASK,
> + icrl & APIC_INT_LEVELTRIG,
> + icrl & APIC_VECTOR_MASK);
> +}
> +
> /*
> * A fast-path version of avic_kick_target_vcpus(), which attempts to match
> * destination APIC ID to vCPU without looping through all vCPUs.
> @@ -427,11 +437,7 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm, struct kvm_lapic *source
> if (unlikely(!target_vcpu))
> return 0;
>
> - target_vcpu->arch.apic->irr_pending = true;
> - svm_complete_interrupt_delivery(target_vcpu,
> - icrl & APIC_MODE_MASK,
> - icrl & APIC_INT_LEVELTRIG,
> - icrl & APIC_VECTOR_MASK);
> + avic_kick_vcpu(target_vcpu, icrl);
> return 0;
> }
>
> @@ -455,13 +461,8 @@ static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
> */
> kvm_for_each_vcpu(i, vcpu, kvm) {
> if (kvm_apic_match_dest(vcpu, source, icrl & APIC_SHORT_MASK,
> - dest, icrl & APIC_DEST_MASK)) {
> - vcpu->arch.apic->irr_pending = true;
> - svm_complete_interrupt_delivery(vcpu,
> - icrl & APIC_MODE_MASK,
> - icrl & APIC_INT_LEVELTRIG,
> - icrl & APIC_VECTOR_MASK);
> - }
> + dest, icrl & APIC_DEST_MASK))
> + avic_kick_vcpu(vcpu, icrl);
> }
> }
>
I don't know what I think about this, sometimes *minor* code duplication might actually
be a good thing, as it is easier to read the code, but I don't have much against this
as well.
I am not sure if before or after this code is more readable.
But anyway,
Reviewed-by: Maxim Levitsky <mlevitsk@xxxxxxxxxx>
Best regards,
Maxim Levitsky
