[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.