Re: radeon in dom0/ivtv in domU: irq 16 nobody cared

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 04/13/2010 06:18 AM, Konrad Rzeszutek Wilk wrote:
> In 2.6.18 there was logic to return IRQ_HANDLED if the IRQ line was
> shared with another guest. Basically this:
>
>
>  914 int irq_ignore_unhandled(unsigned int irq)
>  915 {
>  916         struct physdev_irq_status_query irq_status = { .irq = irq
> };
>  917 
>  918         if (!is_running_on_xen())
>  919                 return 0;
>  920 
>  921         if (HYPERVISOR_physdev_op(PHYSDEVOP_irq_status_query,
> &irq_status))
>  922                 return 0;
>  923         return !!(irq_status.flags & XENIRQSTAT_shared);
>  924 }
>
> Which would be called on any spurrios interrupt and it would
> shortcircuit it. I tried something similar by setting up the fake IRQ
> handler if this hypercall returned a positive value. But the call logic
> in any device driver is that it first does the PCI configuration writes
> (enable the device, etc) and then calls request_irq which binds the
> interrupt to the event channel and then this above hypercall returns
> the shared flag. But the pciback/pcifront isn't used for request_irq
> so I need to figure out some mechanism to schedule this hypercall later
> on in Dom0 to figure out if there is a need to insert the IRQ handler.
>   

Does the kernel get to know about the passed-through irqs?  I was
thinking that at pass-through time it would install the handler in dom0
on the irq (and all other domains sharing the irq), and then the handler
could do that hypercall and return IRQ_HANDLED / IRQ_NONE accordingly.

> Anyhow, my test rig that has a couple of IRQ lines shared across (A Dell
> Dimension something) various devices and is doing something wacky with
> or without this patch where the interrupt lines on the IOAPIC get masked
> (and only if a specific IRQ line gets shared - 17) and no interrupts get
> sent to either Dom0 or DomU. Manually unmasking the IOAPIC starts the
> flow of interrupts thought it becomes a storm. Not sure if it is just
> faulty hardware or operator, so please consider the above code/branch completly
> untested.
>   

Hrm.  You could instrument Xen to see who's masking the interrupt.

    J