On 11.04.2022 12:25, Julien Grall wrote: > On 11/04/2022 07:13, Jan Beulich wrote: >>>>>> --- a/xen/common/event_channel.c >>>>>> +++ b/xen/common/event_channel.c >>>>>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v) >>>>>> unsigned int port; >>>>>> struct evtchn *chn; >>>>>> >>>>>> + /* >>>>>> + * The work done below is an attempt to keep pIRQ-s on the pCPU-s >>>>>> that the >>>>>> + * vCPU-s they're to be delivered to run on. In order to limit lock >>>>>> + * contention, check for an empty list prior to acquiring the lock. >>>>>> In the >>>>>> + * worst case a pIRQ just bound to this vCPU will be delivered >>>>>> elsewhere >>>>>> + * until the vCPU is migrated (again) to another pCPU. >>>>>> + */ >>>>> >>>>> AFAIU, the downside is another pCPU (and therefore vCPU) will get >>>>> disturbed by the interrupt. >>>> >>>> But only rarely, i.e. in case a race would actually have occurred. >>> >>> Maybe I am too paranoid here. The other side of race is controlled by a >>> domain. So wouldn't it be possible to increase how often the race is hit? >> >> Yes, of course - just to harm itself. > > Are you sure? Wouldn't this also harm the next vCPU running on the pCPU > because it will get interrupted more often?
Possibly, sure. But we don't make any promises here. And recall that this optimization as a whole has been put under question in the past. If we'd drop it, we'd also impact various vCPU-s in not really predictable ways. Jan
