WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] radeon in dom0/ivtv in domU: irq 16 nobody cared

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] radeon in dom0/ivtv in domU: irq 16 nobody cared
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 13 Apr 2010 11:30:37 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Hurenkamp <mark.hurenkamp@xxxxxxxxx>
Delivery-date: Tue, 13 Apr 2010 11:34:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100413131804.GB16475@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEB83A1C-247E-4B52-AB14-977664379FDE@xxxxxxxxx> <20100408001916.GA10840@xxxxxxxxxxxxxxxxxxx> <20100408173700.GB26343@xxxxxxxxxxxxxxxxxxx> <4BBE2451.7090600@xxxxxxxx> <20100413131804.GB16475@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4
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