Re: [Xen-devel] [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list
> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > The current VT-d PI related code may operate incorrectly in the following > scenarios: > 1. When VT-d PI is enabled, neen't migrate pirq which is using VT-d PI during neen't -> needn't > vCPU migration. Patch [1/6] solves this by introducing a new flag to indicate > that the pt-irq is delivered through VT-d PI. > > 2. msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. > It wrongly inherits the 'im' field from the live IRTE but updates all the > other > fileds to remapping format. Patch [2/6] handles this. > > 3. [3/6] is a cleanup patch > > 4. When a pCPU is unplugged, and there might be vCPUs on its list. Since the > pCPU is offline, those vCPUs might not be woken up again. [4/6] addresses it. > > 5. IRTE is updated through structure assigment which is unsafe in some cases. > To resolve this, Patch [5/6] provides two variants, atomic and non-atomic, to > update IRTE. And a bug is raised when we can't meet the caller's atomic > requirement. > > 6. We didn't change the IRTE to remapping format when pt-irq is > configurated to have multi-destination vCPUs. Patch [6/6] resolves this > problem. > > > Chao Gao (4): > passthrough: don't migrate pirq when it is delivered through VT-d PI > VT-d: Introduce new fields in msi_desc to track binding with guest > interrupt > VT-d: introduce update_irte to update irte safely > passthrough/io: Fall back to remapping interrupt when we can't use > VT-d PI > > Feng Wu (2): > VT-d: Some cleanups > VMX: Fixup PI descriptor when cpu is offline > > xen/arch/x86/hvm/hvm.c | 3 + > xen/arch/x86/hvm/vmx/vmcs.c| 1 + > xen/arch/x86/hvm/vmx/vmx.c | 70 ++ > xen/arch/x86/msi.c | 2 + > xen/drivers/passthrough/io.c | 71 ++ > xen/drivers/passthrough/vtd/intremap.c | 236 +++-- > > xen/include/asm-x86/hvm/vmx/vmx.h | 1 + > xen/include/asm-x86/msi.h | 3 + > xen/include/xen/hvm/irq.h | 1 + > 9 files changed, 204 insertions(+), 184 deletions(-) > > -- > 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list
The current VT-d PI related code may operate incorrectly in the following scenarios: 1. When VT-d PI is enabled, neen't migrate pirq which is using VT-d PI during vCPU migration. Patch [1/6] solves this by introducing a new flag to indicate that the pt-irq is delivered through VT-d PI. 2. msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. It wrongly inherits the 'im' field from the live IRTE but updates all the other fileds to remapping format. Patch [2/6] handles this. 3. [3/6] is a cleanup patch 4. When a pCPU is unplugged, and there might be vCPUs on its list. Since the pCPU is offline, those vCPUs might not be woken up again. [4/6] addresses it. 5. IRTE is updated through structure assigment which is unsafe in some cases. To resolve this, Patch [5/6] provides two variants, atomic and non-atomic, to update IRTE. And a bug is raised when we can't meet the caller's atomic requirement. 6. We didn't change the IRTE to remapping format when pt-irq is configurated to have multi-destination vCPUs. Patch [6/6] resolves this problem. Chao Gao (4): passthrough: don't migrate pirq when it is delivered through VT-d PI VT-d: Introduce new fields in msi_desc to track binding with guest interrupt VT-d: introduce update_irte to update irte safely passthrough/io: Fall back to remapping interrupt when we can't use VT-d PI Feng Wu (2): VT-d: Some cleanups VMX: Fixup PI descriptor when cpu is offline xen/arch/x86/hvm/hvm.c | 3 + xen/arch/x86/hvm/vmx/vmcs.c| 1 + xen/arch/x86/hvm/vmx/vmx.c | 70 ++ xen/arch/x86/msi.c | 2 + xen/drivers/passthrough/io.c | 71 ++ xen/drivers/passthrough/vtd/intremap.c | 236 +++-- xen/include/asm-x86/hvm/vmx/vmx.h | 1 + xen/include/asm-x86/msi.h | 3 + xen/include/xen/hvm/irq.h | 1 + 9 files changed, 204 insertions(+), 184 deletions(-) -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel