public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, "mingo@elte.hu" <mingo@elte.hu>,
	"tglx@linutronix.de" <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: Thu, 28 Oct 2010 09:22:55 -0700	[thread overview]
Message-ID: <4CC9A35F.1050603@goop.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1010281303330.1407@kaball-desktop>

 On 10/28/2010 05:43 AM, Stefano Stabellini wrote:
> On Tue, 26 Oct 2010, Konrad Rzeszutek Wilk wrote:
>>> 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.
>>
>
> Even though dynamic allocation might seem possible for both pirqs and
> irqs, there are some severe limitations:
>
>
> - Xen won't allocate pirq numbers lower than 16 (probably because it
> expects pirq == gsi for the first 16 gsi), so it might run out
> of pirqs if we ask Xen to always choose the pirq number for us.  As a
> consequence it is safer to keep using pirq == gsi, at least for the
> first 16 gsis. This limitation should probably be fixed in Xen, but we
> need to support older hypervisors so we cannot rely on the fix to be
> present.
>
>
> - Linux expects irq == gsi, see arch/x86/kernel/acpi/boot.c:gsi_to_irq
>
> 	/* Provide an identity mapping of gsi == irq
> 	 * except on truly weird platforms that have
> 	 * non isa irqs in the first 16 gsis.
> 	 */

Yes, we always have to identity map legacy ISA interrupts, and we should
never attempt to dynamically allocate in that region.

    J


  reply	other threads:[~2010-10-28 16:23 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
2010-10-28 12:43                     ` Stefano Stabellini
2010-10-28 16:22                       ` Jeremy Fitzhardinge [this message]
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=4CC9A35F.1050603@goop.org \
    --to=jeremy@goop.org \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stefano.stabellini@eu.citrix.com \
    --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