[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.13] x86/vmx: always sync PIR to IRR before vmentry



On 27.11.2019 12:29, Roger Pau Monné  wrote:
> On Wed, Nov 27, 2019 at 12:16:37PM +0100, Jan Beulich wrote:
>> On 27.11.2019 12:03, Roger Pau Monné  wrote:
>>> On Wed, Nov 27, 2019 at 02:07:16AM +0000, Tian, Kevin wrote:
>>>> Then what's the difference from original logic?
>>>
>>> The original logic is:
>>>
>>> if ( running && (in_irq() || (v != current)) )
>>> {
>>>         unsigned int cpu = v->processor;
>>>
>>>         if ( cpu != smp_processor_id() )
>>>             send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>>>         else if ( !softirq_pending(cpu) )
>>>             raise_softirq(VCPU_KICK_SOFTIRQ);
>>> }
>>>
>>> Which I find much harder to understand. For example I'm not sure of
>>> what's the benefit of doing the cpu != smp_processor_id() check
>>> instead of simply doing v != current (like in the outer if condition).
>>
>> There are two aspects to consider: One is that v->processor
>> may equal smp_processor_id() also for v != current. The other
>> is that without this check in the if() it would need adding
>> to the else-if(). I'm not sure to what degree which of the
>> two matters functionality wise.
> 
> Since the vCPU is running v->processor can only equal smp_processor_id
> if v == current,

What tells you that it is running? It had been running at the
time the flag was latched (before vcpu_unblock()), but may
have got de-scheduled in the meantime.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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