It was noticed that the IRTE configured for guest OS kernel
was over-written while the guest was running. As a result,
vt-d Posted Interrupts configured for the guest are not being
delivered directly, and instead bounces off the host. Every
interrupt delivery takes a VM Exit.
It was noticed that the following stack is doing the over-write:
[ 147.463177] modify_irte+0x171/0x1f0
[ 147.463405] intel_ir_set_affinity+0x5c/0x80
[ 147.463641] msi_domain_set_affinity+0x32/0x90
[ 147.463881] irq_do_set_affinity+0x37/0xd0
[ 147.464125] irq_set_affinity_locked+0x9d/0xb0
[ 147.464374] __irq_set_affinity+0x42/0x70
[ 147.464627] write_irq_affinity.isra.5+0xe1/0x110
[ 147.464895] proc_reg_write+0x38/0x70
[ 147.465150] __vfs_write+0x36/0x180
[ 147.465408] ? handle_mm_fault+0xdf/0x200
[ 147.465671] ? _cond_resched+0x15/0x30
[ 147.465936] vfs_write+0xad/0x1a0
[ 147.466204] SyS_write+0x52/0xc0
[ 147.466472] do_syscall_64+0x74/0x1a0
[ 147.466744] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
reversing the sense of force check in intel_ir_reconfigure_irte()
restores proper posted interrupt functionality
Signed-off-by: Jagannathan Raman <[email protected]>
---
Hi Thomas,
I noticed that you added intel_ir_reconfigure_irte() with the
following commit:
d491bdff888e ("iommu/vt-d: Reevaluate vector configuration on
activate()")
Could you please confirm the usage of "force" parameter in
intel_ir_reconfigure_irte()?
drivers/iommu/intel_irq_remapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
index 66f69af..3062a15 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1136,7 +1136,7 @@ static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force)
irte->dest_id = IRTE_DEST(cfg->dest_apicid);
/* Update the hardware only if the interrupt is in remapped mode. */
- if (!force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
+ if (force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
modify_irte(&ir_data->irq_2_iommu, irte);
}
--
1.8.3.1
On 3/6/2018 5:39 PM, Jagannathan Raman wrote:
> It was noticed that the IRTE configured for guest OS kernel
> was over-written while the guest was running. As a result,
> vt-d Posted Interrupts configured for the guest are not being
> delivered directly, and instead bounces off the host. Every
> interrupt delivery takes a VM Exit.
>
> It was noticed that the following stack is doing the over-write:
> [ 147.463177] modify_irte+0x171/0x1f0
> [ 147.463405] intel_ir_set_affinity+0x5c/0x80
> [ 147.463641] msi_domain_set_affinity+0x32/0x90
> [ 147.463881] irq_do_set_affinity+0x37/0xd0
> [ 147.464125] irq_set_affinity_locked+0x9d/0xb0
> [ 147.464374] __irq_set_affinity+0x42/0x70
> [ 147.464627] write_irq_affinity.isra.5+0xe1/0x110
> [ 147.464895] proc_reg_write+0x38/0x70
> [ 147.465150] __vfs_write+0x36/0x180
> [ 147.465408] ? handle_mm_fault+0xdf/0x200
> [ 147.465671] ? _cond_resched+0x15/0x30
> [ 147.465936] vfs_write+0xad/0x1a0
> [ 147.466204] SyS_write+0x52/0xc0
> [ 147.466472] do_syscall_64+0x74/0x1a0
> [ 147.466744] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>
> reversing the sense of force check in intel_ir_reconfigure_irte()
> restores proper posted interrupt functionality
>
> Signed-off-by: Jagannathan Raman <[email protected]>
> ---
> Hi Thomas,
>
> I noticed that you added intel_ir_reconfigure_irte() with the
> following commit:
> d491bdff888e ("iommu/vt-d: Reevaluate vector configuration on
> activate()")
>
> Could you please confirm the usage of "force" parameter in
> intel_ir_reconfigure_irte()?
>
> drivers/iommu/intel_irq_remapping.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
> index 66f69af..3062a15 100644
> --- a/drivers/iommu/intel_irq_remapping.c
> +++ b/drivers/iommu/intel_irq_remapping.c
> @@ -1136,7 +1136,7 @@ static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force)
> irte->dest_id = IRTE_DEST(cfg->dest_apicid);
>
> /* Update the hardware only if the interrupt is in remapped mode. */
> - if (!force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
> + if (force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
> modify_irte(&ir_data->irq_2_iommu, irte);
> }
>
>
*ping*
> On Apr 4, 2018, at 2:06 PM, Jag Raman <[email protected]> wrote:
>
>
>
> On 3/6/2018 5:39 PM, Jagannathan Raman wrote:
>> It was noticed that the IRTE configured for guest OS kernel
>> was over-written while the guest was running. As a result,
>> vt-d Posted Interrupts configured for the guest are not being
>> delivered directly, and instead bounces off the host. Every
>> interrupt delivery takes a VM Exit.
>> It was noticed that the following stack is doing the over-write:
>> [ 147.463177] modify_irte+0x171/0x1f0
>> [ 147.463405] intel_ir_set_affinity+0x5c/0x80
>> [ 147.463641] msi_domain_set_affinity+0x32/0x90
>> [ 147.463881] irq_do_set_affinity+0x37/0xd0
>> [ 147.464125] irq_set_affinity_locked+0x9d/0xb0
>> [ 147.464374] __irq_set_affinity+0x42/0x70
>> [ 147.464627] write_irq_affinity.isra.5+0xe1/0x110
>> [ 147.464895] proc_reg_write+0x38/0x70
>> [ 147.465150] __vfs_write+0x36/0x180
>> [ 147.465408] ? handle_mm_fault+0xdf/0x200
>> [ 147.465671] ? _cond_resched+0x15/0x30
>> [ 147.465936] vfs_write+0xad/0x1a0
>> [ 147.466204] SyS_write+0x52/0xc0
>> [ 147.466472] do_syscall_64+0x74/0x1a0
>> [ 147.466744] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> reversing the sense of force check in intel_ir_reconfigure_irte()
>> restores proper posted interrupt functionality
>> Signed-off-by: Jagannathan Raman <[email protected]>
>> ---
>> Hi Thomas,
>> I noticed that you added intel_ir_reconfigure_irte() with the
>> following commit:
>> d491bdff888e ("iommu/vt-d: Reevaluate vector configuration on
>> activate()")
>> Could you please confirm the usage of "force" parameter in
>> intel_ir_reconfigure_irte()?
>> drivers/iommu/intel_irq_remapping.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
>> index 66f69af..3062a15 100644
>> --- a/drivers/iommu/intel_irq_remapping.c
>> +++ b/drivers/iommu/intel_irq_remapping.c
>> @@ -1136,7 +1136,7 @@ static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force)
>> irte->dest_id = IRTE_DEST(cfg->dest_apicid);
>> /* Update the hardware only if the interrupt is in remapped mode. */
>> - if (!force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
>> + if (force || ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
>> modify_irte(&ir_data->irq_2_iommu, irte);
>> }
>>
>
> *ping*
*ping*
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Mar 06, 2018 at 05:39:41PM -0500, Jagannathan Raman wrote:
> It was noticed that the IRTE configured for guest OS kernel
> was over-written while the guest was running. As a result,
> vt-d Posted Interrupts configured for the guest are not being
> delivered directly, and instead bounces off the host. Every
> interrupt delivery takes a VM Exit.
>
> It was noticed that the following stack is doing the over-write:
> [ 147.463177] modify_irte+0x171/0x1f0
> [ 147.463405] intel_ir_set_affinity+0x5c/0x80
> [ 147.463641] msi_domain_set_affinity+0x32/0x90
> [ 147.463881] irq_do_set_affinity+0x37/0xd0
> [ 147.464125] irq_set_affinity_locked+0x9d/0xb0
> [ 147.464374] __irq_set_affinity+0x42/0x70
> [ 147.464627] write_irq_affinity.isra.5+0xe1/0x110
> [ 147.464895] proc_reg_write+0x38/0x70
> [ 147.465150] __vfs_write+0x36/0x180
> [ 147.465408] ? handle_mm_fault+0xdf/0x200
> [ 147.465671] ? _cond_resched+0x15/0x30
> [ 147.465936] vfs_write+0xad/0x1a0
> [ 147.466204] SyS_write+0x52/0xc0
> [ 147.466472] do_syscall_64+0x74/0x1a0
> [ 147.466744] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>
> reversing the sense of force check in intel_ir_reconfigure_irte()
> restores proper posted interrupt functionality
>
> Signed-off-by: Jagannathan Raman <[email protected]>
Applie, thanks.