Re: [Xen-devel] [PATCH v5 0/7] VMX: Properly handle pi descriptor and per-cpu blocking list
> -Original Message- > From: Tian, Kevin > Sent: Tuesday, October 11, 2016 4:08 PM > To: Wu, Feng ; xen-devel@lists.xen.org > Cc: jbeul...@suse.com; andrew.coop...@citrix.com; > george.dun...@eu.citrix.com; dario.faggi...@citrix.com > Subject: RE: [PATCH v5 0/7] VMX: Properly handle pi descriptor and per-cpu > blocking list > > > From: Wu, Feng > > Sent: Tuesday, October 11, 2016 8:58 AM > > > > The current VT-d PI related code may operate incorrectly in the > > following scenarios: > > 1. When the last assigned device is dettached from the domain, all > > the PI related hooks are removed then, however, the vCPU can be > > blocked, switched to another pCPU, etc, all without the aware of > > PI. After the next time we attach another device to the domain, > > which makes the PI realted hooks avaliable again, the status > > of the pi descriptor is not true. Besides that, the blocking vcpu > > may still remain in the per-cpu blocking in this case. Patch [1/6] > > and [2/6] handle this. > > Your v5 series have 7 patches in total. Oh, yes, forgot to update this. Should be [1/7] and [2/7] > > > > > 2. After the domain is destroyed, the the blocking vcpu may also > > remain in the per-cpu blocking. Handled in patch [3/6]. [3/7] > > > > 3. When IRTE is in posted mode, we don't need to set the irq > > affinity for it, since the destination of these interrupts is > > vCPU and the vCPU affinity is set during vCPU scheduling. Patch > > [5/6] handles this. [5/7] > > > > 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. [6/6] addresses it. [7/7] Thanks, Feng ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/7] VMX: Properly handle pi descriptor and per-cpu blocking list
> From: Wu, Feng > Sent: Tuesday, October 11, 2016 8:58 AM > > The current VT-d PI related code may operate incorrectly in the > following scenarios: > 1. When the last assigned device is dettached from the domain, all > the PI related hooks are removed then, however, the vCPU can be > blocked, switched to another pCPU, etc, all without the aware of > PI. After the next time we attach another device to the domain, > which makes the PI realted hooks avaliable again, the status > of the pi descriptor is not true. Beside that, the blocking vcpu > may still remain in the per-cpu blocking in this case. Patch [1/6] > and [2/6] handle this. Your v5 series have 7 patches in total. > > 2. After the domain is destroyed, the the blocking vcpu may also > remain in the per-cpu blocking. Handled in patch [3/6]. > > 3. When IRTE is in posted mode, we don't need to set the irq > affinity for it, since the destination of these interrupts is > vCPU and the vCPU affinity is set during vCPU scheduling. Patch > [5/6] handles this. > > 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. [6/6] addresses it. > > Feng Wu (7): > VMX: Statically assign two PI hooks > VMX: Properly handle pi when all the assigned devices are removed > VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed > VMX: Make sure PI is in proper state before install the hooks > VT-d: No need to set irq affinity for posted format IRTE > VT-d: Some cleanups > VMX: Fixup PI descriptor when cpu is offline > > xen/arch/x86/hvm/vmx/vmcs.c| 14 ++--- > xen/arch/x86/hvm/vmx/vmx.c | 112 > ++--- > xen/drivers/passthrough/vtd/intremap.c | 65 --- > xen/include/asm-x86/hvm/vmx/vmx.h | 1 + > 4 files changed, 168 insertions(+), 24 deletions(-) > > -- > 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 0/7] 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 the last assigned device is dettached from the domain, all the PI related hooks are removed then, however, the vCPU can be blocked, switched to another pCPU, etc, all without the aware of PI. After the next time we attach another device to the domain, which makes the PI realted hooks avaliable again, the status of the pi descriptor is not true. Beside that, the blocking vcpu may still remain in the per-cpu blocking in this case. Patch [1/6] and [2/6] handle this. 2. After the domain is destroyed, the the blocking vcpu may also remain in the per-cpu blocking. Handled in patch [3/6]. 3. When IRTE is in posted mode, we don't need to set the irq affinity for it, since the destination of these interrupts is vCPU and the vCPU affinity is set during vCPU scheduling. Patch [5/6] handles this. 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. [6/6] addresses it. Feng Wu (7): VMX: Statically assign two PI hooks VMX: Properly handle pi when all the assigned devices are removed VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed VMX: Make sure PI is in proper state before install the hooks VT-d: No need to set irq affinity for posted format IRTE VT-d: Some cleanups VMX: Fixup PI descriptor when cpu is offline xen/arch/x86/hvm/vmx/vmcs.c| 14 ++--- xen/arch/x86/hvm/vmx/vmx.c | 112 ++--- xen/drivers/passthrough/vtd/intremap.c | 65 --- xen/include/asm-x86/hvm/vmx/vmx.h | 1 + 4 files changed, 168 insertions(+), 24 deletions(-) -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
