Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.09.15 at 03:38, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2015-09-07:
>>>>> On 07.09.15 at 15:00, <yang.z.zhang@xxxxxxxxx> wrote:
>>> Jan Beulich wrote on 2015-09-07:
>>>> Yang, in this context: Why does __vmx_deliver_posted_interrupt()
>>>> not use cpu_raise_softirq(), instead kind of open coding it (see your
>>>> d7dafa375b ["VMX: Add posted interrupt supporting"])?
>>> 
>>> Sorry, I am not in the context. What do you mean of using
>>> cpu_raise_softirq() in __vmx_deliver_posted_interrupt()?
>> 
>> Why is the function not using that ready to use helper? Looking at
>> it ...
>> 
>>> static void __vmx_deliver_posted_interrupt(struct vcpu *v)
>>> {
>>>    bool_t running = v->is_running;
>>>    
>>>    vcpu_unblock(v);
>>>    if ( running && (in_irq() || (v != current)) )
>>>    {
>>>        unsigned int cpu = v->processor;
>>>        
>>>        if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
>> 
>> ... this line as well as ...
>> 
>>>             && (cpu != smp_processor_id()) )
>>>            send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>> 
>> ... this one ...
>> 
>>>    }
>>> }
>> 
>> ... pretty certainly don't belong into vmx.c, or the apparent open
>> coding of cpu_raise_softirq() would require a justifying comment.
> 
> I still don't see how to use cpu_raise_softirq() since the 
> posted_intr_vector doesn't belong to softirq.

I realize that because of the special in-processor treatment of that
vector it ma not be possible to eliminate this open coding. That's why
I said above "would require a justifying comment". After all, namely
with the handler for the vector being the same as for normal event
check interrupts, it is far from obvious why the open coding can't be
avoided.

Jan


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