On 11.04.2022 13:00, Julien Grall wrote: > On 11/04/2022 11:45, Jan Beulich wrote: >> 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. > > I don't remember this discussion. Do you have a pointer?
I'm sorry, but no, I don't have a pointer. This may even have been on irc. All I recall (or at least I think I do) is that it was Andrew who raised the concern. Jan
