Re: [patch 11/26] x64, x2apic/intr-remap: generic irq migration support from process context

[Eric W. Biederman]

Suresh Siddha <suresh.b.siddha@xxxxxxxxx> writes:

> You are referring to desc->lock portion?

yes.

> Two reasons:
>
> a. Other code in CONFIG_GENERIC_PENDING_IRQ, assuming that desc->lock is held
> while calling set_affinity. like fixup_irqs(). Just wanted to be same
> across the board.

Almost useful fixup_irqs is and always has been broken.  So it doesn't really count.

> b. for level triggered, we still touch irq_desc and set IRQ_MOVE_PENDING,
> when we fail to move the irq (if there is already some level triggered
> interrupt happening in parallel). while, we can acquire the lock inside
> the set_affinity, I thought this simplifies things.

Actually if you acquire the lock inside of set_affinity you can sleep,
which may simplify things more.

Fixup_irqs assumes everything happens atomically with irqs disabled so
it doesn't unless you busy wait until the irq is handled.  The best
you can do is if you have an ioxapic force the issue by sending a
directed EOI.  For older apics there is nothing you can do because IPI
are edge triggered and only the acknowledgement of level triggered
interrupts triggers a broadcast EOI for a vector.

Unless you just plain get interested or have a business interest in
true cpu hotplug I don't expect you to fix fixup_irqs.  That is more
work then unifying io_apic.c between x86_32 and x86_64.  Adding yet
another kludge to the kludge is probably fine for now.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/