From: Yang Zhang <yang.zhang.wz@gmail.com>
To: "rkrcmar@redhat.com" <rkrcmar@redhat.com>
Cc: "Wu, Feng" <feng.wu@intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination
Date: Fri, 22 Jan 2016 10:03:16 +0800 [thread overview]
Message-ID: <56A18DE4.80808@gmail.com> (raw)
In-Reply-To: <20160121163545.GA17514@potion.brq.redhat.com>
On 2016/1/22 0:35, rkrcmar@redhat.com wrote:
> 2016-01-21 13:44+0800, Yang Zhang:
>> On 2016/1/21 13:41, Wu, Feng wrote:
>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>>>> We may have different understanding on PI mode. My understanding is if
>>>> we set the IRTE to PI format, than the subsequent interrupt will be
>>>> handled in PI mode. multi-cast and broadcast interrupts cannot be
>>>> injected to guest directly but it doesn't mean cannot be handled in PI
>>>> mode. As i said, we can handle it in wake up vector or via other
>>>> approach.But it is much complexity.
>
> KVM has to intercept the interrupt, so we'd need to trigger a deferred
> work from the notification handler to send the multicast.
> Reusing existing PI vectors would mean slowing them down, so we should
> define a new PI notification vector just for this purpose, which would
> be confusing in /proc/interrupts anyway.
> On top of that, we'd need to define new PIRR array(s) and create unique
> PID for every IRTE, to avoid parsing those PIRR arrays as the vector is
> stored in IRTE ... it's going a bit too far, I guess.
Not so complicated. We can reuse the wake up vector and check whether
the interrupt is multicast when one of destination vcpu handles it. If
it is multicast, then also notifies other vcpus. It is totally handed in
PI mode and we already have the wakeup vector in /proc/interrupts.
>
>>> For the multicast/broastcast, we cannot set the related IRTE in PI
>>> mode, since we cannot set only one destination in IRTE. If an interrupt
>>> is for multiple destination, how can you use VT-d PI to injection it
>>> to all the destinations?
>>
>> You may still not get my point. Anyway, it doesn't matter. Rollback to
>> legacy mode still is the best choice so far.
>
> I think we can't do much better than we do now.
--
best regards
yang
next prev parent reply other threads:[~2016-01-22 2:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 1:42 [PATCH v3 0/4] VT-d posted-interrupts follow ups Feng Wu
2016-01-20 1:42 ` [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Feng Wu
2016-01-21 3:05 ` Yang Zhang
2016-01-21 3:14 ` Wu, Feng
2016-01-21 3:34 ` Yang Zhang
2016-01-21 4:42 ` Wu, Feng
2016-01-21 4:54 ` Tian, Kevin
2016-01-21 4:59 ` Yang Zhang
2016-01-21 5:07 ` Wu, Feng
2016-01-21 5:35 ` Yang Zhang
2016-01-21 5:41 ` Wu, Feng
2016-01-21 5:44 ` Yang Zhang
2016-01-21 16:35 ` rkrcmar
2016-01-22 2:03 ` Yang Zhang [this message]
2016-01-22 13:31 ` rkrcmar
2016-01-25 1:49 ` Yang Zhang
2016-01-25 13:59 ` rkrcmar
2016-01-26 1:44 ` Yang Zhang
2016-01-26 18:22 ` rkrcmar
2016-01-27 2:07 ` Yang Zhang
2016-01-27 15:05 ` rkrcmar
2016-01-21 16:19 ` Radim Krčmář
2016-01-22 1:49 ` Wu, Feng
2016-01-22 13:05 ` Radim Krcmár
2016-01-25 12:22 ` Paolo Bonzini
2016-01-25 12:26 ` Wu, Feng
2016-01-25 12:38 ` Paolo Bonzini
2016-01-25 12:48 ` Wu, Feng
2016-01-25 14:05 ` Radim Krcmár
2016-01-26 0:57 ` Wu, Feng
2016-01-20 1:42 ` [PATCH v3 2/4] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Feng Wu
2016-01-21 5:23 ` Yang Zhang
2016-01-21 5:33 ` Wu, Feng
2016-01-21 5:42 ` Yang Zhang
2016-01-21 5:46 ` Wu, Feng
2016-01-21 5:57 ` Yang Zhang
2016-01-21 6:02 ` Wu, Feng
2016-01-21 6:07 ` Yang Zhang
2016-01-21 17:21 ` rkrcmar
2016-01-22 2:01 ` Wu, Feng
2016-01-22 4:00 ` Yang Zhang
2016-01-22 13:49 ` rkrcmar
2016-01-21 19:49 ` Radim Krčmář
2016-01-22 5:12 ` Wu, Feng
2016-01-22 14:01 ` Radim Krcmár
2016-01-25 12:25 ` Paolo Bonzini
2016-01-25 15:20 ` Radim Krcmár
2016-01-25 16:14 ` Paolo Bonzini
2016-01-26 1:10 ` Wu, Feng
2016-01-20 1:42 ` [PATCH v3 3/4] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Feng Wu
2016-01-21 20:16 ` Radim Krčmář
2016-01-22 5:12 ` Wu, Feng
2016-01-22 14:07 ` Radim Krcmár
2016-01-20 1:42 ` [PATCH v3 4/4] KVM/VMX: Add host irq information in trace event when updating IRTE for posted interrupts Feng Wu
2016-01-21 20:19 ` 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=56A18DE4.80808@gmail.com \
--to=yang.zhang.wz@gmail.com \
--cc=feng.wu@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@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).