From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: radeon in dom0/ivtv in domU: irq 16 nobody cared Date: Tue, 13 Apr 2010 15:10:05 -0400 Message-ID: <20100413191005.GB9173@phenom.dumpdata.com> References: <20100408001916.GA10840@phenom.dumpdata.com> <20100408173700.GB26343@phenom.dumpdata.com> <4BBE2451.7090600@goop.org> <20100413131804.GB16475@phenom.dumpdata.com> <4BC4B84D.1040505@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4BC4B84D.1040505@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Mark Hurenkamp List-Id: xen-devel@lists.xenproject.org > 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. That was my other thought. But that means that the handler has to do a hypercall - which I thought is a bit too heavy handed considering we only need to know whether it is shared only once. The fake irq handler gets disabled if the domain is turned off/pci hotplug removed. Currently the fake IRQ handler is installed on the IRQ that is requested by the guest. So if the IRQ is not shared in Dom0, it still gets inserted in (and it won't receive any interrupts since that IRQ line is not shared with the domain 0). > > > 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. Right now I am, digging through code to figure out how to make this happen without inserting to much code in the handler which would have slowed the machine to a crawl.