All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Feng Wu <feng.wu@intel.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
Date: Wed, 23 Dec 2015 18:19:33 +0100	[thread overview]
Message-ID: <20151223171932.GB7061@potion.redhat.com> (raw)
In-Reply-To: <1450229853-3886-2-git-send-email-feng.wu@intel.com>

2015-12-16 09:37+0800, Feng Wu:
> Use vector-hashing to deliver lowest-priority interrupts, As an
> example, modern Intel CPUs in server platform use this method to
> handle lowest-priority interrupts.
> 
> Signed-off-by: Feng Wu <feng.wu@intel.com>
> ---
> diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> @@ -78,13 +83,25 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,
>  				r = 0;
>  			r += kvm_apic_set_irq(vcpu, irq, dest_map);
>  		} else if (kvm_lapic_enabled(vcpu)) {
> -			if (!lowest)
> -				lowest = vcpu;
> -			else if (kvm_apic_compare_prio(vcpu, lowest) < 0)
> -				lowest = vcpu;
> +			if (!kvm_vector_hashing_enabled()) {
> +				if (!lowest)
> +					lowest = vcpu;
> +				else if (kvm_apic_compare_prio(vcpu, lowest) < 0)
> +					lowest = vcpu;
> +			} else {
> +				__set_bit(vcpu->vcpu_id, dest_vcpu_bitmap);
> +				dest_vcpus++;
> +			}
>  		}
>  	}
>  
> +	if (dest_vcpus != 0) {
> +		idx = kvm_vector_2_index(irq->vector, dest_vcpus,
> +					 dest_vcpu_bitmap, KVM_MAX_VCPUS);
> +
> +		lowest = kvm_get_vcpu(kvm, idx - 1);

This is going to fail with sparse topologies (e.g. 3 cores per socket).
vcpu_id = initial APIC ID and kvm_get_vcpu() uses a compressed array
that has kvm->online_vcpus elements, so we could overflow.

The 'i' in kvm_for_each_vcpu() could be used for the bitmap.
(kvm_get_vcpu_by_id() instead of kvm_get_vcpu() is slightly worse.)

> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> @@ -678,6 +678,22 @@ bool kvm_apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source,
>  bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic *src,
>  		struct kvm_lapic_irq *irq, int *r, unsigned long *dest_map)
>  {
> @@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic *src,
> +			if (!kvm_vector_hashing_enabled()) {
| [...]
> +			} else {
> +				int idx = 0;
> +				unsigned int dest_vcpus = 0;

Now that we don't need to check for present/enabled LAPICs, I think it
would be better to solve this by assuming that all selected LAPICs are
enabled, so the n-th target is decided only based on vector and
destination.

> +				for_each_set_bit(i, &bitmap, 16) {
> +					if (!dst[i] && !kvm_lapic_enabled(dst[i]->vcpu)) {
> +						__clear_bit(i, &bitmap);
> +						continue;
> +					}
> +				}

=> we could skip this loop.

> +
> +				dest_vcpus = hweight16(bitmap);
> +
> +				if (dest_vcpus != 0) {
> +					idx = kvm_vector_2_index(irq->vector,
> +						dest_vcpus, &bitmap, 16);
> +
> +					bitmap = 0;
> +					__set_bit(idx-1, &bitmap);

And set just this bit.

The drawback is that buggy software that included hardware disabled
APICs to lowest priority destinations could stop working ...
Do you think it's too risky?

> +				}
>  			}

(This is basically the same as converting the message to a fixed delivery
 to n-th bit beforehand, so it might be reasonable to to apply something
 similar to simplify the slow path as well.  Mixed flat/cluster/x2APIC
 mode makes me suspect that it won't be reasonable.)

  parent reply	other threads:[~2015-12-23 17:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16  1:37 [PATCH v2 0/2] Add vector-hashing support for lowest-priority interrupts delivery Feng Wu
2015-12-16  1:37 ` [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Feng Wu
2015-12-21  1:46   ` Yang Zhang
2015-12-21  1:50     ` Wu, Feng
2015-12-21  2:06       ` Yang Zhang
2015-12-22  4:37         ` Wu, Feng
2015-12-22  6:49           ` Yang Zhang
2015-12-22  6:59             ` Wu, Feng
2015-12-22  7:13               ` Yang Zhang
2015-12-22  7:19                 ` Wu, Feng
2015-12-22 19:52                   ` rkrcmar
2015-12-23  2:12                     ` Wu, Feng
2015-12-23 16:42                       ` rkrcmar
2015-12-23  3:17                     ` Yang Zhang
2015-12-23 17:19   ` Radim Krčmář [this message]
2016-01-18  5:19     ` Wu, Feng
2016-01-18 10:41       ` Paolo Bonzini
2016-01-19  4:44         ` Wu, Feng
2016-01-19 13:42           ` Paolo Bonzini
2016-01-19 13:49             ` Wu, Feng
2016-01-18 14:00       ` Radim Krcmár
2015-12-16  1:37 ` [PATCH v2 2/2] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Feng Wu
2015-12-21  1:50   ` Yang Zhang
2015-12-21  1:55     ` Wu, Feng
2015-12-21  2:01       ` Yang Zhang
2015-12-22  4:36         ` Wu, Feng
2015-12-22  6:42           ` Yang Zhang
2015-12-23 16:50             ` rkrcmar
2015-12-23 17:21   ` Radim Krčmář
2016-01-04  1:57     ` Wu, Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151223171932.GB7061@potion.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=feng.wu@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.