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
|
Home