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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel