From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
"Lan, Tianyu" <tianyu.lan@intel.com>,
Igor Mammedov <imammedo@redhat.com>,
Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [PATCH 1/9] KVM: x86: add kvm_apic_map_get_dest_lapic
Date: Wed, 25 May 2016 18:02:46 +0200 [thread overview]
Message-ID: <20160525160245.GE14795@potion> (raw)
In-Reply-To: <20160519063606.GA8574@pxdev.xzpeter.org>
2016-05-19 14:36+0800, Peter Xu:
> On Fri, May 06, 2016 at 10:53:57PM +0200, Radim Krčmář wrote:
> > kvm_irq_delivery_to_apic_fast and kvm_intr_is_single_vcpu_fast both
> > compute the interrupt destination. Factor the code.
> >
> > 'struct kvm_lapic **dst = NULL' had to be added to silence GCC.
> > GCC might complain about potential NULL access in the future, because it
> > missed conditions that avoided uninitialized uses of dst.
> >
> > Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
> > ---
> > arch/x86/kvm/lapic.c | 237 +++++++++++++++++++++------------------------------
> > 1 file changed, 99 insertions(+), 138 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 1a2da0e5a373..6812e61c12d4 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -694,14 +694,94 @@ static void kvm_apic_disabled_lapic_found(struct kvm *kvm)
> > }
> > }
> >
> > +/* If kvm_apic_map_get_dest_lapic returns true, then *bitmap encodes accessible
> > + * elements in the *dst array. Those are destinations for the interrupt.
>
> Here, we mentioned that "*bitmap" encodes accessible elements" if
> returns true, while...
>
>> + */
>> +static inline bool kvm_apic_map_get_dest_lapic(struct kvm *kvm, struct kvm_lapic *src,
>> + struct kvm_lapic_irq *irq, struct kvm_apic_map *map,
>> + struct kvm_lapic ***dst, unsigned long *bitmap)
>> +{
>> + int i, lowest;
>> + bool x2apic_ipi;
>> + u16 cid;
>> +
>> + if (irq->shorthand == APIC_DEST_SELF) {
>> + *dst = &src;
>> + *bitmap = 1;
>> + return true;
>> + } else if (irq->shorthand)
>> + return false;
>> +
>> + x2apic_ipi = src && apic_x2apic_mode(src);
>> + if (irq->dest_id == (x2apic_ipi ? X2APIC_BROADCAST : APIC_BROADCAST))
>> + return false;
>> +
>> + if (!map)
>> + return false;
>> +
>> + if (irq->dest_mode == APIC_DEST_PHYSICAL) {
>> + if (irq->dest_id >= ARRAY_SIZE(map->phys_map)) {
>> + *bitmap = 0;
>
> ... here we returned true, but actually we found no real candidates.
> Would it be better that we directly return false in this case? There
> are several similar places in this function as well. Not sure, so
> asked.
kvm_apic_map_get_dest_lapic() returns false if it doesn't know how to
handle the irq, so another function has to be used to get destinations
of the interrupt in question.
'irq->dest_id >= ARRAY_SIZE(map->phys_map)' is a case where we know that
the destination doesn't exist, so asking another function to get
destinations would be pure waste. but the destination doesn't exist, so
*bitmap has to be 0 to avoid invalid accesses.
"return true;" means that **dst offsets encoded in *bitmap are correct
destination(s). Ah, it is horribly convoluted. I am not sure if I can
improve the comment, though ...
> [...]
>
> > @@ -821,69 +835,16 @@ bool kvm_intr_is_single_vcpu_fast(struct kvm *kvm, struct kvm_lapic_irq *irq,
> > rcu_read_lock();
> > map = rcu_dereference(kvm->arch.apic_map);
> >
> > - if (!map)
> > - goto out;
> > + if (kvm_apic_map_get_dest_lapic(kvm, NULL, irq, map, &dst, &bitmap) &&
> > + hweight16(bitmap) == 1) {
>
> If we follow the rule in comment above (return true only if there
> are valid candidates), we may avoid the hweight16(bitmap) == 1
> check as well.
hweight16(bitmap) ranges from 0 to 16. Logical destination mode has
multicast (the maximal addressible unit is one cluster, which has 16
LAPICs), but multicast cannot be optimized by hardware, so we have a
special handling of cases where the destination is just one VCPU.
e.g. for bitmap = 0b100101, the interrupt is directed to dst[0], dst[2]
and dst[5].
next prev parent reply other threads:[~2016-05-25 16:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 20:53 [RFC 0/9] KVM: x86: break the xAPIC barrier Radim Krčmář
2016-05-06 20:53 ` [PATCH 1/9] KVM: x86: add kvm_apic_map_get_dest_lapic Radim Krčmář
2016-05-19 6:36 ` Peter Xu
2016-05-25 16:02 ` Radim Krčmář [this message]
2016-05-26 11:58 ` Peter Xu
2016-05-06 20:53 ` [PATCH 2/9] KVM: x86: dynamic kvm_apic_map Radim Krčmář
2016-05-23 8:04 ` Peter Xu
2016-05-25 16:15 ` Radim Krčmář
2016-05-30 5:24 ` Peter Xu
2016-05-06 20:53 ` [PATCH 3/9] KVM: x86: use u16 for logical VCPU mask in lapic Radim Krčmář
2016-05-06 20:54 ` [PATCH 4/9] KVM: x86: use generic function for MSI parsing Radim Krčmář
2016-05-06 20:54 ` [PATCH 5/9] KVM: support x2APIC ID in userspace routes Radim Krčmář
2016-05-06 20:54 ` [PATCH 6/9] KVM: x86: directly call recalculate_apic_map on lapic restore Radim Krčmář
2016-05-23 8:30 ` Peter Xu
2016-05-06 20:54 ` [PATCH 7/9] KVM: x86: use proper format of APIC ID register Radim Krčmář
2016-05-17 15:34 ` Paolo Bonzini
2016-05-25 16:30 ` Radim Krčmář
2016-05-06 20:54 ` [PATCH 8/9] KVM: x86: reset lapic base in kvm_lapic_reset Radim Krčmář
2016-05-06 20:54 ` [PATCH 9/9] KVM: bump MAX_VCPUS Radim Krčmář
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=20160525160245.GE14795@potion \
--to=rkrcmar@redhat.com \
--cc=imammedo@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=tianyu.lan@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).