Re: [Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Gao, Chao
> Sent: Wednesday, March 01, 2017 2:24 PM
> 
> 
> Good point. I ignore v->processor maybe change. I have thought over
>  __vmx_deliver_posted_interrupt() again and want to share you my
> opinion.
> First of all, __vmx_deliver_posted_interrupt() is to let the target
> vCPU sync PIR to vIRR ASAP.
> different strategies we will used to deal with different cases.
> One is we just unblock the target vCPU when the vCPU is blocked. This can
> make sure the vCPU will go to  vmx_intr_assist() where we achieve the goal.
> The second one is the vCPU is runnable, we will achieve the goal automatically
> when the vCPU is chosen to run.
> The third one is the vCPU is running and running on the same pCPU with the
> source vCPU. It just wants to notify itself. Just raise a softirq is enough.
> The fourth one is the vCPU is running on other pCPU. To notify the target 
> vCPU,
> we send a IPI to the target PCPU which the vCPU is on. Note that when the 
> notification
> arrives to the target PCPU, the target vCPU maybe is blocked, runnable, 
> running in root
> mode,
> or running in non-root mode. If the target vCPU is running in non-root mode, 
> hardware
> will sync PIR to vIRR. If the target vCPU is in non-root mode, the Interrupt 
> handler

non-root -> root

> starts to run. To make sure, we can go back to vmx_intr_assist(), I have 
> suggested that
> the interrupt handler should raise a softirq. If the target vCPU is runnable, 
> we will

Doesn't the current handler already raise a softirq?

> raise a softirq to a wrong vCPU. Maybe it isn't a big issue. If the target 
> vCPU is
> blocked, since before we block a vCPU we will check events through
> local_events_need_delivery()
> , the goal must has been achieved. Also incur a IPI and softirq to a wrong 
> vCPU.
> 
> Combining with Jan's explaination about why v->processor changing is not a 
> problem, I
> think
> we handle all the possible cases. Please let me know if there is something 
> wrong or not
> clear.
> 

overall above looks good to me.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel