[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.