From: Nadav Amit <nadav.amit@gmail.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Wanpeng Li <kernellwp@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kvm <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>, Peter Xu <peterx@redhat.com>,
Yang Zhang <yang.zhang.wz@gmail.com>
Subject: Re: [PATCH v3 03/14] KVM: x86: use physical LAPIC array for logical x2APIC
Date: Tue, 2 Aug 2016 09:40:11 -0700 [thread overview]
Message-ID: <7885D1F8-1077-4B61-A891-757BD808FA35@gmail.com> (raw)
In-Reply-To: <20160802142257.GB15846@potion>
Radim Krčmář <rkrcmar@redhat.com> wrote:
>
> Offending LAPIC marks the logical mapping as unusable, which was
> intended. kvm_apic_map_get_logical_dest() returns false.
>
> The main problem is that SDM does not clearly forbid LAPICs in x2APIC
> mode while some xAPIC LAPICs have nonzero LDR, so we should handle it
> somewhat gracefully.
> In combination with our IR-less IOAPIC hack, this would mean that we
> would have to check both interpretations (x2 and xAPIC) of a logical
> address before delivering. Not to mention that we would also have to
> decide how to handle a case when both interpretations are valid.
My recollection of running Intel tests is that they do leave sometimes
some of the cores in the xAPIC mode while others are in x2APIC mode.
In this case, IIRC they do not generate IPIs from the xAPIC core.
IIRC they do expect broadcast interrupts to be received by all cores,
including those with xAPIC mode. However, I am unsure about this last
point.
Regards,
Nadav
next prev parent reply other threads:[~2016-08-02 16:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 20:09 [PATCH v3 00/14] KVM: x86: break the xAPIC barrier Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 01/14] KVM: x86: bump KVM_SOFT_MAX_VCPUS to 240 Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 02/14] KVM: x86: add kvm_apic_map_get_dest_lapic Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 03/14] KVM: x86: use physical LAPIC array for logical x2APIC Radim Krčmář
2016-08-02 13:46 ` Wanpeng Li
2016-08-02 14:22 ` Radim Krčmář
2016-08-02 16:40 ` Nadav Amit [this message]
2016-07-12 20:09 ` [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map Radim Krčmář
2016-07-13 8:29 ` Paolo Bonzini
2016-07-13 14:37 ` Radim Krčmář
2016-08-02 11:39 ` Wanpeng Li
2016-08-02 12:22 ` Radim Krčmář
2016-08-02 13:15 ` Wanpeng Li
2016-07-12 20:09 ` [PATCH v3 05/14] KVM: x86: use generic function for MSI parsing Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 06/14] KVM: x86: use hardware-compatible format for APIC ID register Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 07/14] KVM: x86: reset APIC ID when enabling LAPIC Radim Krčmář
2016-08-02 13:26 ` Wanpeng Li
2016-08-02 13:52 ` Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 08/14] KVM: VMX: optimize APIC ID read with APICv Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 09/14] KVM: x86: reset lapic base in kvm_lapic_reset Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 10/14] KVM: pass struct kvm to kvm_set_routing_entry Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 11/14] KVM: x86: add KVM_CAP_X2APIC_API Radim Krčmář
2016-07-13 8:41 ` Paolo Bonzini
2016-07-13 14:40 ` Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 12/14] KVM: x86: add a flag to disable KVM x2apic broadcast quirk Radim Krčmář
2016-07-13 8:38 ` Paolo Bonzini
2016-07-13 15:14 ` Radim Krčmář
2016-07-13 15:30 ` Paolo Bonzini
2016-07-13 10:15 ` Paolo Bonzini
2016-07-13 14:52 ` Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 13/14] KVM: x86: bump MAX_VCPUS to 288 Radim Krčmář
2016-07-12 20:09 ` [PATCH v3 14/14] KVM: x86: bump KVM_MAX_VCPU_ID to 1023 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=7885D1F8-1077-4B61-A891-757BD808FA35@gmail.com \
--to=nadav.amit@gmail.com \
--cc=imammedo@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tianyu.lan@intel.com \
--cc=yang.zhang.wz@gmail.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).