From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
mingo@elte.hu, tglx@linutronix.de
Subject: Re: [Xen-devel] Re: [PATCH 1/5] xen: events: use irq_alloc_desc(_at) instead of open-coding an IRQ allocator.
Date: Tue, 26 Oct 2010 13:08:41 -0400 [thread overview]
Message-ID: <20101026170841.GA10708@dumpdata.com> (raw)
In-Reply-To: <4CC70583.2050503@goop.org>
> In that case we should use dynamic allocation for everything. Or try to
> work out distinct irq ranges for different interrupts if you really want
> to keep irq==gsi.
Some little alarm bells are ringing in the back of my head about irq != gsi.
I think the issue was the permission. When a PCI device is allocated to the
PV guest, we do a bunch of xc_* calls to allow the domain to use the BARs
and the IRQ. I believe when the guest boots and tries to map the
event channel with the physical IRQ, one of the arguments is that GSI. And
if we provide a bogus GSI, well, we won't get the INTx to the guest.
As you mentioned, Stefano's patch add a new element to the tuple that can
contain the GSI value. At which point we can make the guest IRQ != GSI,
as long as we can contain the <gsi, event channel> mapping present so
that for the hypercalls we can give it the right GSI.
The MSI/MSI-X use a completly different mechanism that does not all
of this complication, so we are OK with that.
.. snip ..
> d) dynamically allocate all irqs for all event channel types.
<nods> Ok, you sold me on this idea.
next prev parent reply other threads:[~2010-10-26 17:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-77dff1c755c3218691e95e7e38ee14323b35dbdb@git.kernel.org>
2010-10-16 0:15 ` [tip:irq/core] x86: xen: Sanitise sparse_irq handling Jeremy Fitzhardinge
2010-10-16 0:17 ` [Xen-devel] " Jeremy Fitzhardinge
2010-10-16 2:01 ` H. Peter Anvin
2010-10-25 16:22 ` [PATCH 00/05] xen: events: cleanups after irq core improvements (Was: Re: [Xen-devel] Re: [tip:irq/core] x86: xen: Sanitise sparse_irq handling) Ian Campbell
2010-10-25 16:23 ` [PATCH 1/5] xen: events: use irq_alloc_desc(_at) instead of open-coding an IRQ allocator Ian Campbell
2010-10-25 17:35 ` Konrad Rzeszutek Wilk
2010-10-25 18:02 ` Ian Campbell
2010-10-26 8:15 ` [Xen-devel] " Ian Campbell
2010-10-26 19:49 ` Stefano Stabellini
2010-10-26 20:20 ` Jeremy Fitzhardinge
2010-10-25 23:03 ` Jeremy Fitzhardinge
2010-10-25 23:05 ` H. Peter Anvin
2010-10-25 23:21 ` Jeremy Fitzhardinge
2010-10-26 14:17 ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-10-26 16:44 ` Jeremy Fitzhardinge
2010-10-26 17:08 ` Konrad Rzeszutek Wilk [this message]
2010-10-28 12:43 ` Stefano Stabellini
2010-10-28 16:22 ` Jeremy Fitzhardinge
2010-10-25 16:23 ` [PATCH 2/5] xen: events: turn irq_info constructors into initialiser functions Ian Campbell
2010-10-25 16:23 ` [PATCH 3/5] xen: events: push setup of irq<->{evtchn,pirq} maps into irq_info init functions Ian Campbell
2010-10-26 14:31 ` Konrad Rzeszutek Wilk
2010-10-25 16:23 ` [PATCH 4/5] xen: events: dynamically allocate irq info structures Ian Campbell
2010-10-26 14:30 ` Konrad Rzeszutek Wilk
2010-10-26 16:37 ` Jeremy Fitzhardinge
2010-10-25 16:23 ` [PATCH 5/5] xen: events: use per-cpu variable for cpu_evtchn_mask Ian Campbell
2010-10-26 14:36 ` Konrad Rzeszutek Wilk
2010-10-26 14:50 ` Ian Campbell
2010-10-25 23:03 ` [PATCH 00/05] xen: events: cleanups after irq core improvements (Was: Re: [Xen-devel] Re: [tip:irq/core] x86: xen: Sanitise sparse_irq handling) Jeremy Fitzhardinge
2010-10-26 7:25 ` Ian Campbell
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=20101026170841.GA10708@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=hpa@zytor.com \
--cc=ian.campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox