From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: radeon in dom0/ivtv in domU: irq 16 nobody cared Date: Tue, 13 Apr 2010 11:30:37 -0700 Message-ID: <4BC4B84D.1040505@goop.org> References: <20100408001916.GA10840@phenom.dumpdata.com> <20100408173700.GB26343@phenom.dumpdata.com> <4BBE2451.7090600@goop.org> <20100413131804.GB16475@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100413131804.GB16475@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, Mark Hurenkamp List-Id: xen-devel@lists.xenproject.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