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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Nov 10, 2009 at 02:12:03PM +0800, Han, Weidong wrote:
> Jeremy,
> 
> Any comments?


With this patch you can share the PCI devices on the same IRQ, correct? Will
this mean that you can assign to a guest a USB controller, while
Dom0 has controller of the PCI NIC (and assuming that both of those
share the same interrupt line)? If so, won't the Dom0 start throwing
a fit b/c there are unhandled IRQs and eventually disable the IRQ line?


Or even the guest decide that there are too many IRQs and decided to
disable the IRQ line?

> 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.
> > Jeremy Fitzhardinge wrote:

.. snip ..
> >>> 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?

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