RE: [Xen-devel] [PATCH][RFC] pv-ops: fix shared irq device passthrough

["Han, Weidong" <weidong.han@xxxxxxxxx>]

Jeremy Fitzhardinge wrote:
> On 10/26/09 18:32, Han, Weidong wrote:
>>> Hm, not sure about this.  The logic in __setup_irq already looks
>>> pretty tortured, and I'd like to avoid touching it unless there's
>>> definitively a bug in there. 
>>> 
>>> I think the right question is whether probe_irq() is really doing
>>> the right test, and whether it could do something else instead?
>>> 
>> Totally agree. The better way is to change probe_irq, therefore
>> needn't touch kernel irq stuffs. probe_irq is just check if
>> desc->action == NULL or not. The code is there for a long long time
>> (from c/s 26 in linux-2.6.18-xen.hg). I don't know whether it can be
>> replaced.    
>> 
> 
> Could you look into it?  How many drivers do interrupt probing these
> days anyway?  I think we can safely not support ISA devices.
> 
>     J

All devices will call probing_irq in startup_pirq, which bind pirq to event 
channel. But now probing_irq always returns false, then all pirqs are not 
shareable. In my system, a PCI NIC, an USB controller and an IDE interface 
device share the same IRQ 18. Because above reason, pirq 18 is set not 
shareable. So when I hide the PCI NIC, and assign it to guest, it fails in 
guest_bind_pirq, therefore the PCI NIC in guest cannot work, even impact the 
devices who share the IRQ 18.

If don't want to change __setup_irq code like my patch does, current 
probing_irq is useless (always return false). The problem is there is almost no 
information in desc can be used in probing_irq if desc->action is NULL. Keir, 
do you have any ideas?

Regards,
Weidong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel