From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Han, Weidong" <weidong.han@intel.com>
Cc: 'Jeremy Fitzhardinge' <jeremy@goop.org>,
"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
"Kay, Allen M" <allen.m.kay@intel.com>,
"'keir.fraser@eu.citrix.com'" <keir.fraser@eu.citrix.com>
Subject: Re: [PATCH][RFC] pv-ops: fix shared irq device passthrough
Date: Tue, 10 Nov 2009 11:30:58 -0500 [thread overview]
Message-ID: <20091110163058.GB23000@phenom.dumpdata.com> (raw)
In-Reply-To: <715D42877B251141A38726ABF5CABF2C05534DC58B@pdsmsx503.ccr.corp.intel.com>
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?
next prev parent reply other threads:[~2009-11-10 16:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-23 11:39 [PATCH][RFC] pv-ops: fix shared irq device passthrough Han, Weidong
2009-10-26 20:27 ` Jeremy Fitzhardinge
2009-10-27 1:32 ` Han, Weidong
2009-10-29 22:56 ` Jeremy Fitzhardinge
2009-10-30 9:29 ` Han, Weidong
2009-10-30 21:34 ` Jeremy Fitzhardinge
2009-10-31 13:50 ` Han, Weidong
[not found] ` <715D42877B251141A38726ABF5CABF2C055064A406@pdsmsx503.ccr.corp.intel.com>
2009-11-02 10:12 ` Han, Weidong
2009-11-10 6:12 ` Han, Weidong
2009-11-10 6:30 ` Mr. Teo En Ming (Zhang Enming)
2009-11-10 6:59 ` Han, Weidong
2009-11-10 16:30 ` Konrad Rzeszutek Wilk [this message]
2009-11-10 17:11 ` Kay, Allen M
2009-11-10 18:40 ` Konrad Rzeszutek Wilk
2009-11-10 18:44 ` Jeremy Fitzhardinge
2009-11-12 7:15 ` Han, Weidong
2009-11-10 17:56 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091110163058.GB23000@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=allen.m.kay@intel.com \
--cc=jeremy@goop.org \
--cc=keir.fraser@eu.citrix.com \
--cc=weidong.han@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.