Messages in this thread |  | | Subject | Re: [PATCH 2/7] xen/events: don't unmask an event channel when an eoi is pending | From | Jürgen Groß <> | Date | Mon, 8 Feb 2021 11:21:02 +0100 |
| |
On 08.02.21 11:06, Jan Beulich wrote: > On 06.02.2021 11:49, Juergen Gross wrote: >> @@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data) >> ack_dynirq(data); >> } >> >> +static void lateeoi_ack_dynirq(struct irq_data *data) >> +{ >> + struct irq_info *info = info_for_irq(data->irq); >> + evtchn_port_t evtchn = info ? info->evtchn : 0; >> + >> + if (VALID_EVTCHN(evtchn)) { >> + info->eoi_pending = true; >> + mask_evtchn(evtchn); >> + } >> +} >> + >> +static void lateeoi_mask_ack_dynirq(struct irq_data *data) >> +{ >> + struct irq_info *info = info_for_irq(data->irq); >> + evtchn_port_t evtchn = info ? info->evtchn : 0; >> + >> + if (VALID_EVTCHN(evtchn)) { >> + info->masked = true; >> + info->eoi_pending = true; >> + mask_evtchn(evtchn); >> + } >> +} >> + >> static int retrigger_dynirq(struct irq_data *data) >> { >> evtchn_port_t evtchn = evtchn_from_irq(data->irq); >> @@ -2023,8 +2066,8 @@ static struct irq_chip xen_lateeoi_chip __read_mostly = { >> .irq_mask = disable_dynirq, >> .irq_unmask = enable_dynirq, >> >> - .irq_ack = mask_ack_dynirq, >> - .irq_mask_ack = mask_ack_dynirq, >> + .irq_ack = lateeoi_ack_dynirq, >> + .irq_mask_ack = lateeoi_mask_ack_dynirq, >> >> .irq_set_affinity = set_affinity_irq, >> .irq_retrigger = retrigger_dynirq, >> > > Unlike the prior handler the two new ones don't call ack_dynirq() > anymore, and the description doesn't give a hint towards this > difference. As a consequence, clear_evtchn() also doesn't get > called anymore - patch 3 adds the calls, but claims an older > commit to have been at fault. _If_ ack_dynirq() indeed isn't to > be called here, shouldn't the clear_evtchn() calls get added > right here?
There was clearly too much time between writing this patch and looking at its performance impact. :-(
Somehow I managed to overlook that I just introduced the bug here. This OTOH explains why there are not tons of complaints with the current implementation. :-)
Will merge patch 3 into this one.
Juergen [unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] |  |