From: "Radim Krcmár" <rkrcmar@redhat.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@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: Mon, 18 Jan 2016 15:00:13 +0100 [thread overview]
Message-ID: <20160118140012.GA14830@potion.brq.redhat.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F00C2AC860@SHSMSX104.ccr.corp.intel.com>
2016-01-18 05:19+0000, Wu, Feng:
>> From: Radim Krčmář [mailto:rkrcmar@redhat.com]
>> The drawback is that buggy software that included hardware disabled
>> APICs to lowest priority destinations could stop working ...
>
> Yes, if guest hardware disabled the APIC and we don't check "!dst[i]" above,
> interrupts could be still delivered to the hardware disabled APIC, right?
The change allows hardware disabled APIC to be selected, but interrupts
directed to it are (and should be) dropped on subsequent checks.
>> Do you think it's too risky?
>
> If you think the first loop have big bad impact on the performance,
We don't want to do any unnecessary operations in the fast path.
> I think
> your suggestion above is okay, since it is software's responsibility to make
> sure the LAPIC is hardware enabled before receiving the interrupt.
I agree, thanks.
> However,
> this will make the vector-hashing lowest-priority handling slightly different
> compare to round-robin, since RR checks "!dst[i]" before injecting the
> interrupts. What is your opinion about it? Thanks a lot!
I think that differing in forbidden (undefined) cases is not an issue.
(We also differ on broadcast delivery, which goes through the slow path
and currently omits disabled APICs; that's fine with me.)
next prev parent reply other threads:[~2016-01-18 14:00 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ář
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 [this message]
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=20160118140012.GA14830@potion.brq.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 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).