[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.12] pvh/dom0: fix deadlock in GSI mapping
>>> On 28.01.19 at 16:52, <roger.pau@xxxxxxxxxx> wrote: > On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote: >> >>> On 28.01.19 at 15:22, <roger.pau@xxxxxxxxxx> wrote: >> > In order to solve it move the vioapic_hwdom_map_gsi outside of the >> > locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will >> > not access any of the vioapic fields, so there's no need to call the >> > function holding the hvm.irq_lock. >> >> True, but you also move the code across a vioapic_deliver() >> invocation. Is that delivery going to work when >> vioapic_hwdom_map_gsi() gets invoked only afterwards? > > Yes, that vioapic_deliver will only get invoked when there's a pending > gsi (hvm_irq->gsi_assert_count[idx] > 0), and that can only happen > once the hardware gsi is bound to dom0 and the hvm.irq_lock has been > released, so that the dpci softirq can increase the gsi assert count. Oh, I had overlooked the -EEXIST early bail from vioapic_hwdom_map_gsi(), wrongly implying this could be a problem with other than the initial write of an RTE. Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |