[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/3] x86/irq: don't disable domain MSI IRQ on force unbind
On 26.01.2021 12:06, Roger Pau Monne wrote: > When force unbinding a MSI the used IRQ would get added to the domain > irq-pirq tree as -irq -pirq, I think it's -pirq at index irq, i.e. I don't think IRQ gets negated as far as the radix tree goes. info->arch.irq gets a negative value stored, yes. > thus preventing the same IRQ to be used by the domain. Iirc this (answering your post-commit-message question here) is for cleaning up _after_ the domain, i.e. there's no goal to allow re-use of this IRQ. The comment ahead of unmap_domain_pirq() validly says "The pirq should have been unbound before this call." The only time we can't make ourselves dependent upon this is when the guest is being cleaned up. During normal operation I think we actually _want_ to enforce correct behavior of the guest here. > It's not clear to me why we add the irq as -irq -pirq to the irq-pirq > domain tree on forced unbind, as allowing to bind the irq again should > just work regardless of whether it has been previously forcefully > unbound? To continue from the above, see pirq_guest_unbind() where we have if ( desc == NULL ) { irq = -pirq->arch.irq; BUG_ON(irq <= 0); desc = irq_to_desc(irq); spin_lock_irq(&desc->lock); clear_domain_irq_pirq(d, irq, pirq); } as the alternative to going the normal path through __pirq_guest_unbind(). Again iirc that's to cover for the unbind request arriving after the unmap one (i.e. having caused the unmap to force-unbind the IRQ). Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |