>>> On 28.01.19 at 16:52, <roger....@citrix.com> wrote: > On Mon, Jan 28, 2019 at 08:30:02AM -0700, Jan Beulich wrote: >> >>> On 28.01.19 at 15:22, <roger....@citrix.com> 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 <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
