[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Han, Weidong
Sent: 2009年11月2日 18:13
To: 'Jeremy Fitzhardinge'
Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxx'; Kay, Allen M; 'keir.fraser@xxxxxxxxxxxxx'
Subject: RE: [Xen-devel] [PATCH][RFC] pv-ops: fix shared irq device passthrough
Instead of changing kernel __setup_irq and use probing_irq to determine if pirq
is shareable or not, I changed to set shareable flag in irq_info according to
trigger mode in xen_allocate_pirq. Set level triggered interrupts shareable.
This patch doesn't touch kernel IRQ code, it only changes xen related code. Do
you think it is reasonable? Attached the patch.
Han, Weidong wrote:
> Jeremy Fitzhardinge wrote:
>> On 10/30/09 02:29, Han, Weidong wrote:
>>> 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?
>> I think the intent of probing_irq is to detect irqs which are being
>> used to probe for an interrupt during driver initialization. This
>> should only be used for things like ISA which don't have any way to
>> explicitly find out what irq a device is attached to.
>> Given that ISA devices aren't very interesting and no driver should
>> need to do that kind of probing under Xen, I wonder if we can't just
>> remove the whole test?
> Not only ISA devices, but also PCI devices will use probing_irq. ISA
> devices are indeed not interesting, VT-d only assigns PCI devices. In
> fact, Sharing interrupt between assigned devices and host devices is
> not happy situation. We put much effort to make it work long time
> ago. If there is really no good approach, one alternate is add a
> limit of device assignment: don't allow assign PCI devices which
> share interrupt with other devices.
Xen-devel mailing list