[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing
On Thu, Mar 02, 2017 at 07:42:33AM +0000, Xuquan (Quan Xu) wrote: >On March 01, 2017 2:24 PM, wrote: >> >>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 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. > >Does the interrupt handler refer to pi_notification_interrupt() or >event_check_interrupt()? > Yes. Please refer to the v3 patch later. Thanks, Chao _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |