Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1312814 > unrolled thread
| Started by | Feng Wu <feng.wu@intel.com> |
|---|---|
| First post | 2016-01-20 03:10 +0100 |
| Last post | 2016-01-25 13:30 +0100 |
| Articles | 20 on this page of 29 — 8 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Feng Wu <feng.wu@intel.com> - 2016-01-20 03:10 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-21 04:10 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-21 04:20 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-21 04:40 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-21 05:50 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Tian, Kevin" <kevin.tian@intel.com> - 2016-01-21 06:00 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-21 06:00 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-21 06:10 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-21 06:40 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-21 06:50 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "rkrcmar@redhat.com" <rkrcmar@redhat.com> - 2016-01-21 17:40 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-22 03:10 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "rkrcmar@redhat.com" <rkrcmar@redhat.com> - 2016-01-22 14:40 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-25 03:00 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "rkrcmar@redhat.com" <rkrcmar@redhat.com> - 2016-01-25 15:00 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-26 02:50 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "rkrcmar@redhat.com" <rkrcmar@redhat.com> - 2016-01-26 19:30 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Yang Zhang <yang.zhang.wz@gmail.com> - 2016-01-27 03:10 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "rkrcmar@redhat.com" <rkrcmar@redhat.com> - 2016-01-27 16:10 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-21 06:50 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Radim Krčmář <rkrcmar@redhat.com> - 2016-01-21 17:30 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-22 02:50 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Radim Krcmár <rkrcmar@redhat.com> - 2016-01-22 14:10 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-25 13:30 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Paolo Bonzini <pbonzini@redhat.com> - 2016-01-25 13:40 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-25 13:50 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Radim Krcmár <rkrcmar@redhat.com> - 2016-01-25 15:10 +0100
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination "Wu, Feng" <feng.wu@intel.com> - 2016-01-26 02:00 +0100
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Paolo Bonzini <pbonzini@redhat.com> - 2016-01-25 13:30 +0100
Page 1 of 2 [1] 2 Next page →
| From | Feng Wu <feng.wu@intel.com> |
|---|---|
| Date | 2016-01-20 03:10 +0100 |
| Subject | [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qSQnE-8bo-25@gated-at.bofh.it> |
When the interrupt is not single destination any more, we need
to change back IRTE to remapped mode explicitly.
Signed-off-by: Feng Wu <feng.wu@intel.com>
---
arch/x86/kvm/vmx.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e2951b6..13d14d4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm *kvm, unsigned int host_irq,
*/
kvm_set_msi_irq(e, &irq);
- if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
+ if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
+ /*
+ * Make sure the IRTE is in remapped mode if
+ * we don't handle it in posted mode.
+ */
+ pi_set_sn(vcpu_to_pi_desc(vcpu));
+ ret = irq_set_vcpu_affinity(host_irq, NULL);
+ pi_clear_sn(vcpu_to_pi_desc(vcpu));
+
continue;
+ }
vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
vcpu_info.vector = irq.vector;
--
2.1.0
[toc] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-21 04:10 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTdNg-7wj-5@gated-at.bofh.it> |
| In reply to | #1312814 |
On 2016/1/20 9:42, Feng Wu wrote:
> When the interrupt is not single destination any more, we need
> to change back IRTE to remapped mode explicitly.
>
> Signed-off-by: Feng Wu <feng.wu@intel.com>
> ---
> arch/x86/kvm/vmx.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index e2951b6..13d14d4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm *kvm, unsigned int host_irq,
> */
>
> kvm_set_msi_irq(e, &irq);
> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> + /*
> + * Make sure the IRTE is in remapped mode if
> + * we don't handle it in posted mode.
> + */
> + pi_set_sn(vcpu_to_pi_desc(vcpu));
> + ret = irq_set_vcpu_affinity(host_irq, NULL);
> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> +
> continue;
> + }
>
> vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
> vcpu_info.vector = irq.vector;
>
I am still feel weird with this change: according the semantic of VT-d
posted interrupt, the interrupt will injected to guest through posted
notification and /proc/interrupts shows the same meaning. But now,
without being aware of user, the interrupt changes to legacy way and it
appears on different entry on /proc/interrupts. It looks weird.
Any comments? Paolo.
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "Wu, Feng" <feng.wu@intel.com> |
|---|---|
| Date | 2016-01-21 04:20 +0100 |
| Subject | RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTdWV-7Hi-3@gated-at.bofh.it> |
| In reply to | #1313831 |
> -----Original Message-----
> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> Sent: Thursday, January 21, 2016 11:06 AM
> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> rkrcmar@redhat.com
> Cc: linux-kernel@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
>
> On 2016/1/20 9:42, Feng Wu wrote:
> > When the interrupt is not single destination any more, we need
> > to change back IRTE to remapped mode explicitly.
> >
> > Signed-off-by: Feng Wu <feng.wu@intel.com>
> > ---
> > arch/x86/kvm/vmx.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index e2951b6..13d14d4 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> *kvm, unsigned int host_irq,
> > */
> >
> > kvm_set_msi_irq(e, &irq);
> > - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> > + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> > + /*
> > + * Make sure the IRTE is in remapped mode if
> > + * we don't handle it in posted mode.
> > + */
> > + pi_set_sn(vcpu_to_pi_desc(vcpu));
> > + ret = irq_set_vcpu_affinity(host_irq, NULL);
> > + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> > +
> > continue;
> > + }
> >
> > vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
> > vcpu_info.vector = irq.vector;
> >
>
> I am still feel weird with this change: according the semantic of VT-d
> posted interrupt, the interrupt will injected to guest through posted
> notification and /proc/interrupts shows the same meaning. But now,
> without being aware of user, the interrupt changes to legacy way and it
> appears on different entry on /proc/interrupts. It looks weird.
I don't think it has problem here, IMO, this is exactly how it works.
There should be different entry for the interrupts in VT-d PI mode
and leagcy mode.
For VT-d PI mode, it is delivered by notification event, for legacy mode,
it is delivered by VFIO.
Thanks,
Feng
>
> Any comments? Paolo.
>
> --
> best regards
> yang
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-21 04:40 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTegi-7QO-5@gated-at.bofh.it> |
| In reply to | #1313833 |
On 2016/1/21 11:14, Wu, Feng wrote:
>
>
>> -----Original Message-----
>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>> Sent: Thursday, January 21, 2016 11:06 AM
>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>> rkrcmar@redhat.com
>> Cc: linux-kernel@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
>>
>> On 2016/1/20 9:42, Feng Wu wrote:
>>> When the interrupt is not single destination any more, we need
>>> to change back IRTE to remapped mode explicitly.
>>>
>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
>>> ---
>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index e2951b6..13d14d4 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
>> *kvm, unsigned int host_irq,
>>> */
>>>
>>> kvm_set_msi_irq(e, &irq);
>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
>>> + /*
>>> + * Make sure the IRTE is in remapped mode if
>>> + * we don't handle it in posted mode.
>>> + */
>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
>>> +
>>> continue;
>>> + }
>>>
>>> vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
>>> vcpu_info.vector = irq.vector;
>>>
>>
>> I am still feel weird with this change: according the semantic of VT-d
>> posted interrupt, the interrupt will injected to guest through posted
>> notification and /proc/interrupts shows the same meaning. But now,
>> without being aware of user, the interrupt changes to legacy way and it
>> appears on different entry on /proc/interrupts. It looks weird.
>
> I don't think it has problem here, IMO, this is exactly how it works.
> There should be different entry for the interrupts in VT-d PI mode
> and leagcy mode.
I am not saying any problem here. Just feel weird. From a normal user's
point, he has turned on the VT-d pi and according the semantic of VT-d
pi, he should not observe the interrupt through legacy mode, but now he
do see it. Maybe print out a message here will be helpful, like what you
did for disabled lapic found during irq injection.
>
> For VT-d PI mode, it is delivered by notification event, for legacy mode,
> it is delivered by VFIO.
>
> Thanks,
> Feng
>
>>
>> Any comments? Paolo.
>>
>> --
>> best regards
>> yang
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "Wu, Feng" <feng.wu@intel.com> |
|---|---|
| Date | 2016-01-21 05:50 +0100 |
| Subject | RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTfm1-5Y-3@gated-at.bofh.it> |
| In reply to | #1313838 |
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
> Behalf Of Yang Zhang
> Sent: Thursday, January 21, 2016 11:35 AM
> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> rkrcmar@redhat.com
> Cc: linux-kernel@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
>
> On 2016/1/21 11:14, Wu, Feng wrote:
> >
> >
> >> -----Original Message-----
> >> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> >> Sent: Thursday, January 21, 2016 11:06 AM
> >> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >> rkrcmar@redhat.com
> >> Cc: linux-kernel@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
> >>
> >> On 2016/1/20 9:42, Feng Wu wrote:
> >>> When the interrupt is not single destination any more, we need
> >>> to change back IRTE to remapped mode explicitly.
> >>>
> >>> Signed-off-by: Feng Wu <feng.wu@intel.com>
> >>> ---
> >>> arch/x86/kvm/vmx.c | 11 ++++++++++-
> >>> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >>> index e2951b6..13d14d4 100644
> >>> --- a/arch/x86/kvm/vmx.c
> >>> +++ b/arch/x86/kvm/vmx.c
> >>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> >> *kvm, unsigned int host_irq,
> >>> */
> >>>
> >>> kvm_set_msi_irq(e, &irq);
> >>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> >>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> >>> + /*
> >>> + * Make sure the IRTE is in remapped mode if
> >>> + * we don't handle it in posted mode.
> >>> + */
> >>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
> >>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
> >>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> >>> +
> >>> continue;
> >>> + }
> >>>
> >>> vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
> >>> vcpu_info.vector = irq.vector;
> >>>
> >>
> >> I am still feel weird with this change: according the semantic of VT-d
> >> posted interrupt, the interrupt will injected to guest through posted
> >> notification and /proc/interrupts shows the same meaning. But now,
> >> without being aware of user, the interrupt changes to legacy way and it
> >> appears on different entry on /proc/interrupts. It looks weird.
> >
> > I don't think it has problem here, IMO, this is exactly how it works.
> > There should be different entry for the interrupts in VT-d PI mode
> > and leagcy mode.
>
> I am not saying any problem here. Just feel weird. From a normal user's
> point, he has turned on the VT-d pi and according the semantic of VT-d
> pi, he should not observe the interrupt through legacy mode, but now he
> do see it. Maybe print out a message here will be helpful, like what you
> did for disabled lapic found during irq injection.
Even VT-d PI is on, not all interrupts can be handled by it, the reason the
interrupts is changed back to legacy mode is because the user changes
the affinity, and it cannot be handle in PI mode, and hence legacy mode
is used. It is the user's behavior that cause this mode change, seems it is
not so weird to me. But add some message here is good idea, just like
what I did later in this function, I can also add the following trace
message here.
trace_kvm_pi_irte_update(vcpu->vcpu_id, host_irq, e->gsi,
vcpu_info.vector, vcpu_info.pi_desc_addr, set);
Thanks,
Feng
>
> >
> > For VT-d PI mode, it is delivered by notification event, for legacy mode,
> > it is delivered by VFIO.
> >
> > Thanks,
> > Feng
> >
> >>
> >> Any comments? Paolo.
> >>
> >> --
> >> best regards
> >> yang
>
>
> --
> best regards
> yang
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | "Tian, Kevin" <kevin.tian@intel.com> |
|---|---|
| Date | 2016-01-21 06:00 +0100 |
| Subject | RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTfvI-9j-7@gated-at.bofh.it> |
| In reply to | #1313858 |
> From: Wu, Feng
> Sent: Thursday, January 21, 2016 12:43 PM
>
> > -----Original Message-----
> > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
> > Behalf Of Yang Zhang
> > Sent: Thursday, January 21, 2016 11:35 AM
> > To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> > rkrcmar@redhat.com
> > Cc: linux-kernel@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
> >
> > On 2016/1/21 11:14, Wu, Feng wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> > >> Sent: Thursday, January 21, 2016 11:06 AM
> > >> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> > >> rkrcmar@redhat.com
> > >> Cc: linux-kernel@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
> > >>
> > >> On 2016/1/20 9:42, Feng Wu wrote:
> > >>> When the interrupt is not single destination any more, we need
> > >>> to change back IRTE to remapped mode explicitly.
> > >>>
> > >>> Signed-off-by: Feng Wu <feng.wu@intel.com>
> > >>> ---
> > >>> arch/x86/kvm/vmx.c | 11 ++++++++++-
> > >>> 1 file changed, 10 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > >>> index e2951b6..13d14d4 100644
> > >>> --- a/arch/x86/kvm/vmx.c
> > >>> +++ b/arch/x86/kvm/vmx.c
> > >>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> > >> *kvm, unsigned int host_irq,
> > >>> */
> > >>>
> > >>> kvm_set_msi_irq(e, &irq);
> > >>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> > >>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> > >>> + /*
> > >>> + * Make sure the IRTE is in remapped mode if
> > >>> + * we don't handle it in posted mode.
> > >>> + */
> > >>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
> > >>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
> > >>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> > >>> +
> > >>> continue;
> > >>> + }
> > >>>
> > >>> vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
> > >>> vcpu_info.vector = irq.vector;
> > >>>
> > >>
> > >> I am still feel weird with this change: according the semantic of VT-d
> > >> posted interrupt, the interrupt will injected to guest through posted
> > >> notification and /proc/interrupts shows the same meaning. But now,
> > >> without being aware of user, the interrupt changes to legacy way and it
> > >> appears on different entry on /proc/interrupts. It looks weird.
> > >
> > > I don't think it has problem here, IMO, this is exactly how it works.
> > > There should be different entry for the interrupts in VT-d PI mode
> > > and leagcy mode.
> >
> > I am not saying any problem here. Just feel weird. From a normal user's
> > point, he has turned on the VT-d pi and according the semantic of VT-d
> > pi, he should not observe the interrupt through legacy mode, but now he
> > do see it. Maybe print out a message here will be helpful, like what you
> > did for disabled lapic found during irq injection.
>
> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
> interrupts is changed back to legacy mode is because the user changes
> the affinity, and it cannot be handle in PI mode, and hence legacy mode
> is used. It is the user's behavior that cause this mode change, seems it is
> not so weird to me. But add some message here is good idea, just like
> what I did later in this function, I can also add the following trace
> message here.
>
> trace_kvm_pi_irte_update(vcpu->vcpu_id, host_irq, e->gsi,
> vcpu_info.vector, vcpu_info.pi_desc_addr, set);
>
> Thanks,
> Feng
>
Right. Whether the interrupt is delivered into guest directly with PI or with
legacy mode, is completely agnostic to the guest. Guest can't tell
or set any expectation on the underlying delivering method, so there is no
guest visible impact.
Thanks
Kevin
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-21 06:00 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTfvI-9j-5@gated-at.bofh.it> |
| In reply to | #1313858 |
On 2016/1/21 12:42, Wu, Feng wrote:
>
>
>> -----Original Message-----
>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
>> Behalf Of Yang Zhang
>> Sent: Thursday, January 21, 2016 11:35 AM
>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>> rkrcmar@redhat.com
>> Cc: linux-kernel@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
>>
>> On 2016/1/21 11:14, Wu, Feng wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>>>> Sent: Thursday, January 21, 2016 11:06 AM
>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>> rkrcmar@redhat.com
>>>> Cc: linux-kernel@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
>>>>
>>>> On 2016/1/20 9:42, Feng Wu wrote:
>>>>> When the interrupt is not single destination any more, we need
>>>>> to change back IRTE to remapped mode explicitly.
>>>>>
>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
>>>>> ---
>>>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>>>> index e2951b6..13d14d4 100644
>>>>> --- a/arch/x86/kvm/vmx.c
>>>>> +++ b/arch/x86/kvm/vmx.c
>>>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
>>>> *kvm, unsigned int host_irq,
>>>>> */
>>>>>
>>>>> kvm_set_msi_irq(e, &irq);
>>>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
>>>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
>>>>> + /*
>>>>> + * Make sure the IRTE is in remapped mode if
>>>>> + * we don't handle it in posted mode.
>>>>> + */
>>>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
>>>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
>>>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
>>>>> +
>>>>> continue;
>>>>> + }
>>>>>
>>>>> vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
>>>>> vcpu_info.vector = irq.vector;
>>>>>
>>>>
>>>> I am still feel weird with this change: according the semantic of VT-d
>>>> posted interrupt, the interrupt will injected to guest through posted
>>>> notification and /proc/interrupts shows the same meaning. But now,
>>>> without being aware of user, the interrupt changes to legacy way and it
>>>> appears on different entry on /proc/interrupts. It looks weird.
>>>
>>> I don't think it has problem here, IMO, this is exactly how it works.
>>> There should be different entry for the interrupts in VT-d PI mode
>>> and leagcy mode.
>>
>> I am not saying any problem here. Just feel weird. From a normal user's
>> point, he has turned on the VT-d pi and according the semantic of VT-d
>> pi, he should not observe the interrupt through legacy mode, but now he
>> do see it. Maybe print out a message here will be helpful, like what you
>> did for disabled lapic found during irq injection.
>
> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
No, we can handle it but we don't do it due to the complexity.For
example, we can use wake up vector to delivery the interrupt which still
is in PI mode but doesn't require any mode change.
> interrupts is changed back to legacy mode is because the user changes
> the affinity, and it cannot be handle in PI mode, and hence legacy mode
> is used. It is the user's behavior that cause this mode change, seems it is
> not so weird to me. But add some message here is good idea, just like
Why user's behavior can change the mode? According the current design,
there is no way for user to turn on/off dynamically.Why we need to
rollback to legacy mode is we don't want to handle multi-destination
interrupt in PI mode but it doesn't mean we cannot do it like i said before.
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "Wu, Feng" <feng.wu@intel.com> |
|---|---|
| Date | 2016-01-21 06:10 +0100 |
| Subject | RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTfFp-tF-17@gated-at.bofh.it> |
| In reply to | #1313864 |
> -----Original Message-----
> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> Sent: Thursday, January 21, 2016 1:00 PM
> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> rkrcmar@redhat.com
> Cc: linux-kernel@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
>
> On 2016/1/21 12:42, Wu, Feng wrote:
> >
> >
> >> -----Original Message-----
> >> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> On
> >> Behalf Of Yang Zhang
> >> Sent: Thursday, January 21, 2016 11:35 AM
> >> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >> rkrcmar@redhat.com
> >> Cc: linux-kernel@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
> >>
> >> On 2016/1/21 11:14, Wu, Feng wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> >>>> Sent: Thursday, January 21, 2016 11:06 AM
> >>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >>>> rkrcmar@redhat.com
> >>>> Cc: linux-kernel@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
> >>>>
> >>>> On 2016/1/20 9:42, Feng Wu wrote:
> >>>>> When the interrupt is not single destination any more, we need
> >>>>> to change back IRTE to remapped mode explicitly.
> >>>>>
> >>>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
> >>>>> ---
> >>>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
> >>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >>>>> index e2951b6..13d14d4 100644
> >>>>> --- a/arch/x86/kvm/vmx.c
> >>>>> +++ b/arch/x86/kvm/vmx.c
> >>>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> >>>> *kvm, unsigned int host_irq,
> >>>>> */
> >>>>>
> >>>>> kvm_set_msi_irq(e, &irq);
> >>>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> >>>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> >>>>> + /*
> >>>>> + * Make sure the IRTE is in remapped mode if
> >>>>> + * we don't handle it in posted mode.
> >>>>> + */
> >>>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
> >>>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
> >>>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> >>>>> +
> >>>>> continue;
> >>>>> + }
> >>>>>
> >>>>> vcpu_info.pi_desc_addr =
> __pa(vcpu_to_pi_desc(vcpu));
> >>>>> vcpu_info.vector = irq.vector;
> >>>>>
> >>>>
> >>>> I am still feel weird with this change: according the semantic of VT-d
> >>>> posted interrupt, the interrupt will injected to guest through posted
> >>>> notification and /proc/interrupts shows the same meaning. But now,
> >>>> without being aware of user, the interrupt changes to legacy way and it
> >>>> appears on different entry on /proc/interrupts. It looks weird.
> >>>
> >>> I don't think it has problem here, IMO, this is exactly how it works.
> >>> There should be different entry for the interrupts in VT-d PI mode
> >>> and leagcy mode.
> >>
> >> I am not saying any problem here. Just feel weird. From a normal user's
> >> point, he has turned on the VT-d pi and according the semantic of VT-d
> >> pi, he should not observe the interrupt through legacy mode, but now he
> >> do see it. Maybe print out a message here will be helpful, like what you
> >> did for disabled lapic found during irq injection.
> >
> > Even VT-d PI is on, not all interrupts can be handled by it, the reason the
>
> No, we can handle it but we don't do it due to the complexity.For
> example, we can use wake up vector to delivery the interrupt which still
> is in PI mode but doesn't require any mode change.
I mean, multi-cast and broadcast interrupts cannot be handled in PI mode.
>
> > interrupts is changed back to legacy mode is because the user changes
> > the affinity, and it cannot be handle in PI mode, and hence legacy mode
> > is used. It is the user's behavior that cause this mode change, seems it is
> > not so weird to me. But add some message here is good idea, just like
>
> Why user's behavior can change the mode?
Like you mentioned before, if the interrupt is changed from single-destination
to multiple-destination by guest. And this is the reason of adding the rollback
logic here, right?
Thanks,
Feng
> According the current design,
> there is no way for user to turn on/off dynamically.Why we need to
> rollback to legacy mode is we don't want to handle multi-destination
> interrupt in PI mode but it doesn't mean we cannot do it like i said before.
>
>
> --
> best regards
> yang
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-21 06:40 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTg8C-Im-35@gated-at.bofh.it> |
| In reply to | #1313869 |
On 2016/1/21 13:07, Wu, Feng wrote:
>
>
>> -----Original Message-----
>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>> Sent: Thursday, January 21, 2016 1:00 PM
>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>> rkrcmar@redhat.com
>> Cc: linux-kernel@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
>>
>> On 2016/1/21 12:42, Wu, Feng wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
>> On
>>>> Behalf Of Yang Zhang
>>>> Sent: Thursday, January 21, 2016 11:35 AM
>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>> rkrcmar@redhat.com
>>>> Cc: linux-kernel@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
>>>>
>>>> On 2016/1/21 11:14, Wu, Feng wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>>>>>> Sent: Thursday, January 21, 2016 11:06 AM
>>>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>>>> rkrcmar@redhat.com
>>>>>> Cc: linux-kernel@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
>>>>>>
>>>>>> On 2016/1/20 9:42, Feng Wu wrote:
>>>>>>> When the interrupt is not single destination any more, we need
>>>>>>> to change back IRTE to remapped mode explicitly.
>>>>>>>
>>>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
>>>>>>> ---
>>>>>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
>>>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>>>>>> index e2951b6..13d14d4 100644
>>>>>>> --- a/arch/x86/kvm/vmx.c
>>>>>>> +++ b/arch/x86/kvm/vmx.c
>>>>>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
>>>>>> *kvm, unsigned int host_irq,
>>>>>>> */
>>>>>>>
>>>>>>> kvm_set_msi_irq(e, &irq);
>>>>>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
>>>>>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
>>>>>>> + /*
>>>>>>> + * Make sure the IRTE is in remapped mode if
>>>>>>> + * we don't handle it in posted mode.
>>>>>>> + */
>>>>>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
>>>>>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
>>>>>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
>>>>>>> +
>>>>>>> continue;
>>>>>>> + }
>>>>>>>
>>>>>>> vcpu_info.pi_desc_addr =
>> __pa(vcpu_to_pi_desc(vcpu));
>>>>>>> vcpu_info.vector = irq.vector;
>>>>>>>
>>>>>>
>>>>>> I am still feel weird with this change: according the semantic of VT-d
>>>>>> posted interrupt, the interrupt will injected to guest through posted
>>>>>> notification and /proc/interrupts shows the same meaning. But now,
>>>>>> without being aware of user, the interrupt changes to legacy way and it
>>>>>> appears on different entry on /proc/interrupts. It looks weird.
>>>>>
>>>>> I don't think it has problem here, IMO, this is exactly how it works.
>>>>> There should be different entry for the interrupts in VT-d PI mode
>>>>> and leagcy mode.
>>>>
>>>> I am not saying any problem here. Just feel weird. From a normal user's
>>>> point, he has turned on the VT-d pi and according the semantic of VT-d
>>>> pi, he should not observe the interrupt through legacy mode, but now he
>>>> do see it. Maybe print out a message here will be helpful, like what you
>>>> did for disabled lapic found during irq injection.
>>>
>>> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
>>
>> No, we can handle it but we don't do it due to the complexity.For
>> example, we can use wake up vector to delivery the interrupt which still
>> is in PI mode but doesn't require any mode change.
>
> I mean, multi-cast and broadcast interrupts cannot be handled in PI mode.
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.
I agree that rollback to legacy mode is the best choice, but may need
some additional messages to tell the user(host administrator) why we
change to legacy mode. I think not all of them are familiar with the
detail of VT-d PI. If they find there are still some interrupts goto
legacy mode even they have turned on PI, they may get confused.
>
>>
>>> interrupts is changed back to legacy mode is because the user changes
>>> the affinity, and it cannot be handle in PI mode, and hence legacy mode
>>> is used. It is the user's behavior that cause this mode change, seems it is
>>> not so weird to me. But add some message here is good idea, just like
>>
>> Why user's behavior can change the mode?
>
> Like you mentioned before, if the interrupt is changed from single-destination
> to multiple-destination by guest. And this is the reason of adding the rollback
> logic here, right?
The user means the host administrator.
>
> Thanks,
> Feng
>
>> According the current design,
>> there is no way for user to turn on/off dynamically.Why we need to
>> rollback to legacy mode is we don't want to handle multi-destination
>> interrupt in PI mode but it doesn't mean we cannot do it like i said before.
>>
>>
>> --
>> best regards
>> yang
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-21 06:50 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTgi6-LZ-7@gated-at.bofh.it> |
| In reply to | #1313913 |
On 2016/1/21 13:41, Wu, Feng wrote:
>
>
>> -----Original Message-----
>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>> Sent: Thursday, January 21, 2016 1:36 PM
>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>> rkrcmar@redhat.com
>> Cc: linux-kernel@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
>>
>> On 2016/1/21 13:07, Wu, Feng wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>>>> Sent: Thursday, January 21, 2016 1:00 PM
>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>> rkrcmar@redhat.com
>>>> Cc: linux-kernel@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
>>>>
>>>> On 2016/1/21 12:42, Wu, Feng wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
>>>> On
>>>>>> Behalf Of Yang Zhang
>>>>>> Sent: Thursday, January 21, 2016 11:35 AM
>>>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>>>> rkrcmar@redhat.com
>>>>>> Cc: linux-kernel@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
>>>>>>
>>>>>> On 2016/1/21 11:14, Wu, Feng wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
>>>>>>>> Sent: Thursday, January 21, 2016 11:06 AM
>>>>>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
>>>>>>>> rkrcmar@redhat.com
>>>>>>>> Cc: linux-kernel@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
>>>>>>>>
>>>>>>>> On 2016/1/20 9:42, Feng Wu wrote:
>>>>>>>>> When the interrupt is not single destination any more, we need
>>>>>>>>> to change back IRTE to remapped mode explicitly.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
>>>>>>>>> ---
>>>>>>>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
>>>>>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>>>>>>>> index e2951b6..13d14d4 100644
>>>>>>>>> --- a/arch/x86/kvm/vmx.c
>>>>>>>>> +++ b/arch/x86/kvm/vmx.c
>>>>>>>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct
>> kvm
>>>>>>>> *kvm, unsigned int host_irq,
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> kvm_set_msi_irq(e, &irq);
>>>>>>>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
>>>>>>>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
>>>>>>>>> + /*
>>>>>>>>> + * Make sure the IRTE is in remapped mode if
>>>>>>>>> + * we don't handle it in posted mode.
>>>>>>>>> + */
>>>>>>>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
>>>>>>>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
>>>>>>>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
>>>>>>>>> +
>>>>>>>>> continue;
>>>>>>>>> + }
>>>>>>>>>
>>>>>>>>> vcpu_info.pi_desc_addr =
>>>> __pa(vcpu_to_pi_desc(vcpu));
>>>>>>>>> vcpu_info.vector = irq.vector;
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am still feel weird with this change: according the semantic of VT-d
>>>>>>>> posted interrupt, the interrupt will injected to guest through posted
>>>>>>>> notification and /proc/interrupts shows the same meaning. But now,
>>>>>>>> without being aware of user, the interrupt changes to legacy way and
>> it
>>>>>>>> appears on different entry on /proc/interrupts. It looks weird.
>>>>>>>
>>>>>>> I don't think it has problem here, IMO, this is exactly how it works.
>>>>>>> There should be different entry for the interrupts in VT-d PI mode
>>>>>>> and leagcy mode.
>>>>>>
>>>>>> I am not saying any problem here. Just feel weird. From a normal user's
>>>>>> point, he has turned on the VT-d pi and according the semantic of VT-d
>>>>>> pi, he should not observe the interrupt through legacy mode, but now
>> he
>>>>>> do see it. Maybe print out a message here will be helpful, like what you
>>>>>> did for disabled lapic found during irq injection.
>>>>>
>>>>> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
>>>>
>>>> No, we can handle it but we don't do it due to the complexity.For
>>>> example, we can use wake up vector to delivery the interrupt which still
>>>> is in PI mode but doesn't require any mode change.
>>>
>>> I mean, multi-cast and broadcast interrupts cannot be handled in PI mode.
>>
>> 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.
>
> 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.
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "rkrcmar@redhat.com" <rkrcmar@redhat.com> |
|---|---|
| Date | 2016-01-21 17:40 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTqr8-7RN-19@gated-at.bofh.it> |
| In reply to | #1313926 |
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. >>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.
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-22 03:10 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTzkK-5CO-3@gated-at.bofh.it> |
| In reply to | #1314338 |
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
[toc] | [prev] | [next] | [standalone]
| From | "rkrcmar@redhat.com" <rkrcmar@redhat.com> |
|---|---|
| Date | 2016-01-22 14:40 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTK6t-4Fl-5@gated-at.bofh.it> |
| In reply to | #1314712 |
2016-01-22 10:03+0800, Yang Zhang: > 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. I'm not sure what you mean now ... I guess it is: - Deliver the interrupt to a guest VCPU and relay the multicast to other VCPUs. No, it's strictly worse than intercepting it in the host. - Modify host's wakeup vector handler to send the multicast. It's so complicated, because all information you start with in the host is a vector number. You start with no idea what the multicast interrupt should be. We could add per-multicast PID to the list of parsed PIDs in wakeup_handler and use PID->multicast interrupt mapping to tell which interrupt we should send, but that seems worse than just delivering a non-remapped interrupt. Also, if wakeup vector were used for wakeup and multicast, we'd be uselessly doing work, because we can't tell which reason triggered the interrupt before finishing one part -- using separate vectors for that would be a bit nicer.
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-25 03:00 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qUEBJ-513-3@gated-at.bofh.it> |
| In reply to | #1314976 |
On 2016/1/22 21:31, rkrcmar@redhat.com wrote: > 2016-01-22 10:03+0800, Yang Zhang: >> 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. > > I'm not sure what you mean now ... I guess it is: > - Deliver the interrupt to a guest VCPU and relay the multicast to other > VCPUs. No, it's strictly worse than intercepting it in the host. It is still handled in host context not guest context. The wakeup event cannot be consumed like posted event. So it relies on hypervisor to inject the interrupt to guest. We can add the check at this point. > > - Modify host's wakeup vector handler to send the multicast. > It's so complicated, because all information you start with in the > host is a vector number. You start with no idea what the multicast > interrupt should be. > > We could add per-multicast PID to the list of parsed PIDs in > wakeup_handler and use PID->multicast interrupt mapping to tell which > interrupt we should send, but that seems worse than just delivering a > non-remapped interrupt. > > Also, if wakeup vector were used for wakeup and multicast, we'd be > uselessly doing work, because we can't tell which reason triggered the > interrupt before finishing one part -- using separate vectors for that > would be a bit nicer. > -- best regards yang
[toc] | [prev] | [next] | [standalone]
| From | "rkrcmar@redhat.com" <rkrcmar@redhat.com> |
|---|---|
| Date | 2016-01-25 15:00 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qUPQu-4Ie-7@gated-at.bofh.it> |
| In reply to | #1316162 |
2016-01-25 09:49+0800, Yang Zhang:
> On 2016/1/22 21:31, rkrcmar@redhat.com wrote:
>>2016-01-22 10:03+0800, Yang Zhang:
>>>Not so complicated. We can reuse the wake up vector and check whether the
>>>interrupt is multicast when one of destination vcpu handles it.
>>
>>I'm not sure what you mean now ... I guess it is:
>>- Deliver the interrupt to a guest VCPU and relay the multicast to other
>> VCPUs. No, it's strictly worse than intercepting it in the host.
>
> It is still handled in host context not guest context. The wakeup event
> cannot be consumed like posted event.
Ok. ("when one of destination vcpu handles it" confused me into
thinking that you'd like to handle it with the notification vector.)
> So it relies on hypervisor to inject
> the interrupt to guest. We can add the check at this point.
Yes, but I don't think we want to do that, because of following
drawbacks:
>>- Modify host's wakeup vector handler to send the multicast.
>> It's so complicated, because all information you start with in the
>> host is a vector number. You start with no idea what the multicast
>> interrupt should be.
>>
>> We could add per-multicast PID to the list of parsed PIDs in
>> wakeup_handler and use PID->multicast interrupt mapping to tell which
>> interrupt we should send, but that seems worse than just delivering a
>> non-remapped interrupt.
(should have been "remapped, but non-posted".)
>> Also, if wakeup vector were used for wakeup and multicast, we'd be
>> uselessly doing work, because we can't tell which reason triggered the
>> interrupt before finishing one part -- using separate vectors for that
>> would be a bit nicer.
(imprecise -- we would always have to check for ON bit of all PIDs from
blocked VCPUs, for the original meaning of wakeup vector, and always
either read the PIRR or check for ON bit of all PIDs that encode
multicast interrupts; then we have to clear ON bits for multicasts.)
---
There might be a benefit of using posted interrupts for host interrupts
when we run out of free interrupt vectors: we could start using vectors
by multiple sources through posted interrupts, if using posted
interrupts is the fastest way to distinguish the interrupt source.
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-26 02:50 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qV0VA-4hz-7@gated-at.bofh.it> |
| In reply to | #1316718 |
On 2016/1/25 21:59, rkrcmar@redhat.com wrote:
> 2016-01-25 09:49+0800, Yang Zhang:
>> On 2016/1/22 21:31, rkrcmar@redhat.com wrote:
>>> 2016-01-22 10:03+0800, Yang Zhang:
>>>> Not so complicated. We can reuse the wake up vector and check whether the
>>>> interrupt is multicast when one of destination vcpu handles it.
>>>
>>> I'm not sure what you mean now ... I guess it is:
>>> - Deliver the interrupt to a guest VCPU and relay the multicast to other
>>> VCPUs. No, it's strictly worse than intercepting it in the host.
>>
>> It is still handled in host context not guest context. The wakeup event
>> cannot be consumed like posted event.
>
> Ok. ("when one of destination vcpu handles it" confused me into
> thinking that you'd like to handle it with the notification vector.)
Sorry for my poor english. :(
>
>> So it relies on hypervisor to inject
>> the interrupt to guest. We can add the check at this point.
>
> Yes, but I don't think we want to do that, because of following
> drawbacks:
>
>>> - Modify host's wakeup vector handler to send the multicast.
>>> It's so complicated, because all information you start with in the
>>> host is a vector number. You start with no idea what the multicast
>>> interrupt should be.
>>>
>>> We could add per-multicast PID to the list of parsed PIDs in
>>> wakeup_handler and use PID->multicast interrupt mapping to tell which
>>> interrupt we should send, but that seems worse than just delivering a
>>> non-remapped interrupt.
>
> (should have been "remapped, but non-posted".)
>
>>> Also, if wakeup vector were used for wakeup and multicast, we'd be
>>> uselessly doing work, because we can't tell which reason triggered the
>>> interrupt before finishing one part -- using separate vectors for that
>>> would be a bit nicer.
>
> (imprecise -- we would always have to check for ON bit of all PIDs from
> blocked VCPUs, for the original meaning of wakeup vector, and always
This is what KVM does currently.
> either read the PIRR or check for ON bit of all PIDs that encode
> multicast interrupts; then we have to clear ON bits for multicasts.)
Also, most part of work is covered by current logic except checking the
multicast.
>
>
> ---
> There might be a benefit of using posted interrupts for host interrupts
> when we run out of free interrupt vectors: we could start using vectors
> by multiple sources through posted interrupts, if using posted
Do you mean per vcpu posted interrupts?
> interrupts is the fastest way to distinguish the interrupt source.
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "rkrcmar@redhat.com" <rkrcmar@redhat.com> |
|---|---|
| Date | 2016-01-26 19:30 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qVgxk-83o-17@gated-at.bofh.it> |
| In reply to | #1317457 |
2016-01-26 09:44+0800, Yang Zhang:
> On 2016/1/25 21:59, rkrcmar@redhat.com wrote:
>>2016-01-25 09:49+0800, Yang Zhang:
>>>On 2016/1/22 21:31, rkrcmar@redhat.com wrote:
>>>>2016-01-22 10:03+0800, Yang Zhang:
>>>>>Not so complicated. We can reuse the wake up vector and check whether the
>>>>>interrupt is multicast when one of destination vcpu handles it.
>>>>
>>>>I'm not sure what you mean now ... I guess it is:
>>>>- Deliver the interrupt to a guest VCPU and relay the multicast to other
>>>> VCPUs. No, it's strictly worse than intercepting it in the host.
>>>
>>>It is still handled in host context not guest context. The wakeup event
>>>cannot be consumed like posted event.
>>
>>Ok. ("when one of destination vcpu handles it" confused me into
>>thinking that you'd like to handle it with the notification vector.)
>
> Sorry for my poor english. :(
It's good. Ambiguity is hard to avoid if a reader doesn't want to
assume only the most likely meaning.
>>>> Also, if wakeup vector were used for wakeup and multicast, we'd be
>>>> uselessly doing work, because we can't tell which reason triggered the
>>>> interrupt before finishing one part -- using separate vectors for that
>>>> would be a bit nicer.
>>
>>(imprecise -- we would always have to check for ON bit of all PIDs from
>> blocked VCPUs, for the original meaning of wakeup vector, and always
>
> This is what KVM does currently.
Yep.
>> either read the PIRR or check for ON bit of all PIDs that encode
>> multicast interrupts; then we have to clear ON bits for multicasts.)
>
> Also, most part of work is covered by current logic except checking the
> multicast.
We could reuse the setup that gets us to wakeup_handler, but there is
nothing to share in the handler itself. Sharing a handler means that we
always have to execute both parts.
We must create new PID anyway and compared to the extra work needed for
multicast handling, a new vector + handler is a relatively small code
investment that adds clarity to the design (and performance).
(Taking the vector splitting to the extreme, we'd improve performance if
we added a vector per assigned device. That is practically the same as
non-posted mode, just more complicated.)
>>---
>>There might be a benefit of using posted interrupts for host interrupts
>>when we run out of free interrupt vectors: we could start using vectors
>>by multiple sources through posted interrupts, if using posted
>
> Do you mean per vcpu posted interrupts?
I mean using posting for host device interrupts (no virt involved).
Let's say we have 300 devices for one CPU and CPU has 200 useable
vectors. We have 100 device interrupts that need to be shared in some
vectors and using posting might be faster than directly checking
multiple devices.
(I couldn't come up with a plausible scenario where we might want to use
posting for host interrupts.)
[toc] | [prev] | [next] | [standalone]
| From | Yang Zhang <yang.zhang.wz@gmail.com> |
|---|---|
| Date | 2016-01-27 03:10 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qVnIt-4QH-5@gated-at.bofh.it> |
| In reply to | #1318221 |
On 2016/1/27 2:22, rkrcmar@redhat.com wrote:
> 2016-01-26 09:44+0800, Yang Zhang:
>> On 2016/1/25 21:59, rkrcmar@redhat.com wrote:
>>> 2016-01-25 09:49+0800, Yang Zhang:
>>>> On 2016/1/22 21:31, rkrcmar@redhat.com wrote:
>>>>> 2016-01-22 10:03+0800, Yang Zhang:
>>>>>> Not so complicated. We can reuse the wake up vector and check whether the
>>>>>> interrupt is multicast when one of destination vcpu handles it.
>>>>>
>>>>> I'm not sure what you mean now ... I guess it is:
>>>>> - Deliver the interrupt to a guest VCPU and relay the multicast to other
>>>>> VCPUs. No, it's strictly worse than intercepting it in the host.
>>>>
>>>> It is still handled in host context not guest context. The wakeup event
>>>> cannot be consumed like posted event.
>>>
>>> Ok. ("when one of destination vcpu handles it" confused me into
>>> thinking that you'd like to handle it with the notification vector.)
>>
>> Sorry for my poor english. :(
>
> It's good. Ambiguity is hard to avoid if a reader doesn't want to
> assume only the most likely meaning.
>
>>>>> Also, if wakeup vector were used for wakeup and multicast, we'd be
>>>>> uselessly doing work, because we can't tell which reason triggered the
>>>>> interrupt before finishing one part -- using separate vectors for that
>>>>> would be a bit nicer.
>>>
>>> (imprecise -- we would always have to check for ON bit of all PIDs from
>>> blocked VCPUs, for the original meaning of wakeup vector, and always
>>
>> This is what KVM does currently.
>
> Yep.
>
>>> either read the PIRR or check for ON bit of all PIDs that encode
>>> multicast interrupts; then we have to clear ON bits for multicasts.)
>>
>> Also, most part of work is covered by current logic except checking the
>> multicast.
>
> We could reuse the setup that gets us to wakeup_handler, but there is
> nothing to share in the handler itself. Sharing a handler means that we
> always have to execute both parts.
I don't quite understand it. There is nothing need to be modified for
wakeup logic. The only thing we need to do is add the checking before
the vcpu pick up the pending interrupt(This is happened in VCPU context,
not in handler).
>
> We must create new PID anyway and compared to the extra work needed for
> multicast handling, a new vector + handler is a relatively small code
> investment that adds clarity to the design (and performance).
No new PID is needed. If the target vcpu is running, no additional work
is required in wakeup handler. If target vcpu is not running, the
current logic will wake up the vcpu, then let vcpu itself to check
whether pending interrupt is a multicast and handle it in vcpu's context.
>
> (Taking the vector splitting to the extreme, we'd improve performance if
> we added a vector per assigned device. That is practically the same as
> non-posted mode, just more complicated.)
>
>>> ---
>>> There might be a benefit of using posted interrupts for host interrupts
>>> when we run out of free interrupt vectors: we could start using vectors
>>> by multiple sources through posted interrupts, if using posted
>>
>> Do you mean per vcpu posted interrupts?
>
> I mean using posting for host device interrupts (no virt involved).
>
> Let's say we have 300 devices for one CPU and CPU has 200 useable
> vectors. We have 100 device interrupts that need to be shared in some
> vectors and using posting might be faster than directly checking
> multiple devices.
Yes, this is an good point.
--
best regards
yang
[toc] | [prev] | [next] | [standalone]
| From | "rkrcmar@redhat.com" <rkrcmar@redhat.com> |
|---|---|
| Date | 2016-01-27 16:10 +0100 |
| Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qVzTj-5mj-1@gated-at.bofh.it> |
| In reply to | #1318549 |
2016-01-27 10:07+0800, Yang Zhang: > On 2016/1/27 2:22, rkrcmar@redhat.com wrote: >>2016-01-26 09:44+0800, Yang Zhang: >>>On 2016/1/25 21:59, rkrcmar@redhat.com wrote: >>>>>> Also, if wakeup vector were used for wakeup and multicast, we'd be >>>>>> uselessly doing work, because we can't tell which reason triggered the >>>>>> interrupt before finishing one part -- using separate vectors for that >>>>>> would be a bit nicer. >>>> >>>>(imprecise -- we would always have to check for ON bit of all PIDs from >>>> blocked VCPUs, for the original meaning of wakeup vector, and always >>>> either read the PIRR or check for ON bit of all PIDs that encode >>>> multicast interrupts; then we have to clear ON bits for multicasts.) >>> >>>Also, most part of work is covered by current logic except checking the >>>multicast. >> >>We could reuse the setup that gets us to wakeup_handler, but there is >>nothing to share in the handler itself. Sharing a handler means that we >>always have to execute both parts. > > I don't quite understand it. There is nothing need to be modified for wakeup > logic. The only thing we need to do is add the checking before the vcpu pick > up the pending interrupt(This is happened in VCPU context, not in handler). I see, there are few problems with that. >>We must create new PID anyway and compared to the extra work needed for >>multicast handling, a new vector + handler is a relatively small code >>investment that adds clarity to the design (and performance). > > No new PID is needed. If the target vcpu is running, no additional work is > required in wakeup handler. If target vcpu is not running, the current logic > will wake up the vcpu, then let vcpu itself to check whether pending > interrupt is a multicast and handle it in vcpu's context. We do need a new PID. The existing VCPU PID switches between wakeup vector and notification vector, so if the VCPU was running when the device triggered an interrupt, we'd deliver the posted interrupt without exiting, but we need to handle the interrupt in the host. => We need at least one PID that is never set to notification vector. Reusing VCPU's PIRR is in new PID(s) is not doable. Parsing PIRR would be our only option of recognizing multicast interrupts and if the guest configured many sources to send the same vector, we'd have to do unacceptable things to tell which one was triggered. => We also need at least on one new PIRR. Handling the interrupt in VCPU context doesn't pose any advantage and we even want to do it outside, because all VCPUs can be running when the interrupt arrives and can therefore be posted further. I hope I covered other disadvantages of PIDs and PIRRs earlier.
[toc] | [prev] | [next] | [standalone]
| From | "Wu, Feng" <feng.wu@intel.com> |
|---|---|
| Date | 2016-01-21 06:50 +0100 |
| Subject | RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination |
| Message-ID | <qTgi6-LZ-9@gated-at.bofh.it> |
| In reply to | #1313913 |
> -----Original Message-----
> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> Sent: Thursday, January 21, 2016 1:36 PM
> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> rkrcmar@redhat.com
> Cc: linux-kernel@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
>
> On 2016/1/21 13:07, Wu, Feng wrote:
> >
> >
> >> -----Original Message-----
> >> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> >> Sent: Thursday, January 21, 2016 1:00 PM
> >> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >> rkrcmar@redhat.com
> >> Cc: linux-kernel@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
> >>
> >> On 2016/1/21 12:42, Wu, Feng wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> >> On
> >>>> Behalf Of Yang Zhang
> >>>> Sent: Thursday, January 21, 2016 11:35 AM
> >>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >>>> rkrcmar@redhat.com
> >>>> Cc: linux-kernel@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
> >>>>
> >>>> On 2016/1/21 11:14, Wu, Feng wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Yang Zhang [mailto:yang.zhang.wz@gmail.com]
> >>>>>> Sent: Thursday, January 21, 2016 11:06 AM
> >>>>>> To: Wu, Feng <feng.wu@intel.com>; pbonzini@redhat.com;
> >>>>>> rkrcmar@redhat.com
> >>>>>> Cc: linux-kernel@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
> >>>>>>
> >>>>>> On 2016/1/20 9:42, Feng Wu wrote:
> >>>>>>> When the interrupt is not single destination any more, we need
> >>>>>>> to change back IRTE to remapped mode explicitly.
> >>>>>>>
> >>>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com>
> >>>>>>> ---
> >>>>>>> arch/x86/kvm/vmx.c | 11 ++++++++++-
> >>>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> >>>>>>> index e2951b6..13d14d4 100644
> >>>>>>> --- a/arch/x86/kvm/vmx.c
> >>>>>>> +++ b/arch/x86/kvm/vmx.c
> >>>>>>> @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct
> kvm
> >>>>>> *kvm, unsigned int host_irq,
> >>>>>>> */
> >>>>>>>
> >>>>>>> kvm_set_msi_irq(e, &irq);
> >>>>>>> - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> >>>>>>> + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> >>>>>>> + /*
> >>>>>>> + * Make sure the IRTE is in remapped mode if
> >>>>>>> + * we don't handle it in posted mode.
> >>>>>>> + */
> >>>>>>> + pi_set_sn(vcpu_to_pi_desc(vcpu));
> >>>>>>> + ret = irq_set_vcpu_affinity(host_irq, NULL);
> >>>>>>> + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> >>>>>>> +
> >>>>>>> continue;
> >>>>>>> + }
> >>>>>>>
> >>>>>>> vcpu_info.pi_desc_addr =
> >> __pa(vcpu_to_pi_desc(vcpu));
> >>>>>>> vcpu_info.vector = irq.vector;
> >>>>>>>
> >>>>>>
> >>>>>> I am still feel weird with this change: according the semantic of VT-d
> >>>>>> posted interrupt, the interrupt will injected to guest through posted
> >>>>>> notification and /proc/interrupts shows the same meaning. But now,
> >>>>>> without being aware of user, the interrupt changes to legacy way and
> it
> >>>>>> appears on different entry on /proc/interrupts. It looks weird.
> >>>>>
> >>>>> I don't think it has problem here, IMO, this is exactly how it works.
> >>>>> There should be different entry for the interrupts in VT-d PI mode
> >>>>> and leagcy mode.
> >>>>
> >>>> I am not saying any problem here. Just feel weird. From a normal user's
> >>>> point, he has turned on the VT-d pi and according the semantic of VT-d
> >>>> pi, he should not observe the interrupt through legacy mode, but now
> he
> >>>> do see it. Maybe print out a message here will be helpful, like what you
> >>>> did for disabled lapic found during irq injection.
> >>>
> >>> Even VT-d PI is on, not all interrupts can be handled by it, the reason the
> >>
> >> No, we can handle it but we don't do it due to the complexity.For
> >> example, we can use wake up vector to delivery the interrupt which still
> >> is in PI mode but doesn't require any mode change.
> >
> > I mean, multi-cast and broadcast interrupts cannot be handled in PI mode.
>
> 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.
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?
Thanks,
Feng
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web