|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.
>>> On 23.09.15 at 11:08, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Wed, Sep 23, 2015 at 8:42 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 23.09.15 at 05:50, <yang.z.zhang@xxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1678,8 +1678,9 @@ static void __vmx_deliver_posted_interrupt(struct
>>> vcpu
> *v)
>>> {
>>> unsigned int cpu = v->processor;
>>>
>>> - if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
>>> - && (cpu != smp_processor_id()) )
>>> + if ( !test_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
>>> + && pi_test_on(&v->arch.hvm_vmx.pi_desc)
>>> + && (cpu != smp_processor_id()))
>>> send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>>> }
>>> }
>>
>> So this still removes the setting of the softirq - how can that be
>> correct (namely in the cpu == smp_processor_id() case)? Did you
>> perhaps mean
>>
>> if ( pi_test_on(&v->arch.hvm_vmx.pi_desc)
>> && !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
>> && (cpu != smp_processor_id()))
>
> So the problem before was setting the SOFTIRQ for another cpu but then
> never sending an interrupt?
No, the problem is a performance one, resulting from there being
too many softirqs (often, but not always pointlessly raised). At
least that's my recollection from earlier discussion here.
> Is there a reason why this code isn't using cpu_raise_softirq() here,
> rather than manually doing the same thing (and doing it incorrectly,
> apparently)?
I had asked the same question. The subtle difference being the vector
that gets used for the IPI.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |