Not sure if the change is a bit over-kill, since enable_pirq is has void
return type, while startup_pirq is "int" return type, with possibility
to fail.
For example, in following situation, the startup_pirq may fail : 1) when
startup_pirq again, fail to get free port, 2) if another domain try to
bind the pirq with BIND_PIRQ_WILL_SHARE cleared (like to probing, will
it happen?) between the shutdown_pirq/startup_pirq sequence.
-- Yunhong Jiang
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
> All,
> I have a laptop here that has some interrupt trouble,
> unrelated to Xen (I
> believe it's a bug in the ACPI tables, but I digress). On the
bare-metal
> kernel, if 999,900 out of 100,000 interrupts go
> un-acknowledged to a particular
> interrupt line, the kernel disables that interrupt line. In
> the Xen kernel, the
> same logic applies. However, when the Xen kernel goes to
> disable the physical
> interrupt, it only masks out the event channel:
>
> static void disable_pirq(unsigned int irq)
> {
> int evtchn = evtchn_from_irq(irq);
>
> if (VALID_EVTCHN(evtchn))
> mask_evtchn(evtchn);
> }
>
> And at this point, *all* interrupts on the affected machine
> seem to stop, not
> just this physical IRQ line. I believe the problem is that
> when we go to
> disable a PIRQ, we actually need to get the HV to mask it out
> on the IOAPIC.
> This patch does exactly that; on disable_pirq(), we actually
> just call out to
> shutdown_pirq(), which ends up hypercalling and getting the HV
> to mask out the
> interrupt. On the other side, I needed to modify
> enable_pirq() to call out to
> startup_pirq(), so that it would actually allocate the event channel.
>
> With this patch in place, the affected laptop no longer hangs
> up when the kernel
> decides to disable that particular interrupt line.
>
> Signed-off-by: Chris Lalancette <clalance@xxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home