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

["Xuquan (Quan Xu)" <xuquan8@xxxxxxxxxx>]

On February 23, 2017 8:27 PM, Jan Beulich wrote:
>>>> On 23.02.17 at 12:55, <xuquan8@xxxxxxxxxx> wrote:
>> On February 23, 2017 7:01 PM, Jan Beulich wrote:
>>>>>> On 23.02.17 at 11:53, <xuquan8@xxxxxxxxxx> wrote:
>>>> IOW,
>>>>  which vcpu does the 'current' refer to?
>>>>  which cpu does the ' smp_processor_id()' refer to?
>>>
>>>current: currently running vCPU
>>
>> in a SMP machine, are there more than one currently running vCPU?
>
>Of course. "current" obviously is the one running on the CPU we're on.
>

Jan,
Another question, it 'd be the _main_gap_.. 
If the pCPU runs __vmx_deliver_posted_interrupt() here, in a hyperver-context,
_iiuc_, all of vCPUs , waiting in the run queue, are scheduled out.. So the 
'current' is NULL, as there is no running vCPU..

correct me!!

Quan




>> I think so, the condition "if ( running && (in_irq() || (v !=
>> current)) )", in
>> __vmx_deliver_posted_interrupt() looks strange -- when vCPU is
>> running, why to check ' v != current '..
>>
>>
>>>smp_processor_id(): processor ID of the CPU we're running on
>>>
>> I think if vcpu is running, ' cpu != smp_processor_id() ' should be true.
>>
>>
>> I think we could simplify __vmx_deliver_posted_interrupt():
>>
>>    1. set VCPU_KICK_SOFTIRQ bit of v->processor.
>>    2. IF vcpu is running:
>>          - send_IPI
>>      ELSE
>>          - vcpu_kick
>
>If this can be done in a race free manner (after all, the running state of a 
>vCPU
>running on another pCPU may change at any
>time) ...
>
>Jan


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