From: Jeremy Fitzhardinge <jeremy@goop.org> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Date: Thu, 18 Jun 2009 12:34:20 -0700 [thread overview] Message-ID: <4A3A96BC.1000302@goop.org> (raw) In-Reply-To: <m1zlc6memu.fsf@fess.ebiederm.org> On 06/17/09 19:58, Eric W. Biederman wrote: >> One of the options we discussed was changing the API to get rid of the exposed >> vector, and just replace it with an operation to directly bind a gsi to a pirq >> (internal Xen physical interrupt handle, if you will), so that Xen ends up doing >> all the I/O APIC programming internally, as well as the local APIC. >> > > As an abstraction layer I think that will work out a lot better long term. > > Given what iommus with irqs and DMA I expect you want something like > that, that can be used from domU. Then you just make allowing the > operation conditional on if you happen to have the associated hardware > mapped into your domain. > A domU with a PCI passthrough device can bind a pirq to one of its event channels. All the gsi->pirq binding happens in dom0, but binding a pirq to event channel can happen anywhere (that's why it doesn't bind gsi directly to event channel, as they're strictly per-domain). MSI interrupts also get bound to pirqs, so once the binding is created, MSI and GSI interrupts can be treated identically (I think, I haven't looked into the details yet). >> On the Linux side, I think it means we can just point pcibios_enable/disable_irq >> to our own xen_pci_irq_enable/disable functions to create the binding between a >> PCI device and an irq. >> > > If you want xen to assign the linux irq number that is absolutely the properly place > to hook. > Yes. We'd want to keep the irq==gsi mapping for non-MSI interrupts, but that's easy enough to arrange. > When I was messing with the irq code I did not recall finding many > cases where migrating irqs from process context worked without hitting > hardware bugs. ioapic state machine lockups and the like. > Keir mentioned that Xen avoids masking/unmasking interrupts in the I/O APIC too much, because that has been problematic in the past. Is that related to the problems you're talking about? Is there anywhere which documents them? > How does Xen handle domU with hardware directly mapped? > We call that "pci passthrough". Dom0 will bind the gsi to a pirq as usual, and then pass the pirq through to the domU. The domU will bind the pirq to an event channel, which gets mapped to a Linux irq and handled as usual. > Temporally ignoring what we have to do to work with Xen 3.4. I'm curious > if we could make the Xen dom0 irq case the same as the Xen domU case. > It is already; once the pirq is prepared, the process is the same in both cases. J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Xen-devel <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Keir Fraser <keir.fraser@eu.citrix.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de> Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Date: Thu, 18 Jun 2009 12:34:20 -0700 [thread overview] Message-ID: <4A3A96BC.1000302@goop.org> (raw) In-Reply-To: <m1zlc6memu.fsf@fess.ebiederm.org> On 06/17/09 19:58, Eric W. Biederman wrote: >> One of the options we discussed was changing the API to get rid of the exposed >> vector, and just replace it with an operation to directly bind a gsi to a pirq >> (internal Xen physical interrupt handle, if you will), so that Xen ends up doing >> all the I/O APIC programming internally, as well as the local APIC. >> > > As an abstraction layer I think that will work out a lot better long term. > > Given what iommus with irqs and DMA I expect you want something like > that, that can be used from domU. Then you just make allowing the > operation conditional on if you happen to have the associated hardware > mapped into your domain. > A domU with a PCI passthrough device can bind a pirq to one of its event channels. All the gsi->pirq binding happens in dom0, but binding a pirq to event channel can happen anywhere (that's why it doesn't bind gsi directly to event channel, as they're strictly per-domain). MSI interrupts also get bound to pirqs, so once the binding is created, MSI and GSI interrupts can be treated identically (I think, I haven't looked into the details yet). >> On the Linux side, I think it means we can just point pcibios_enable/disable_irq >> to our own xen_pci_irq_enable/disable functions to create the binding between a >> PCI device and an irq. >> > > If you want xen to assign the linux irq number that is absolutely the properly place > to hook. > Yes. We'd want to keep the irq==gsi mapping for non-MSI interrupts, but that's easy enough to arrange. > When I was messing with the irq code I did not recall finding many > cases where migrating irqs from process context worked without hitting > hardware bugs. ioapic state machine lockups and the like. > Keir mentioned that Xen avoids masking/unmasking interrupts in the I/O APIC too much, because that has been problematic in the past. Is that related to the problems you're talking about? Is there anywhere which documents them? > How does Xen handle domU with hardware directly mapped? > We call that "pci passthrough". Dom0 will bind the gsi to a pirq as usual, and then pass the pirq through to the domU. The domU will bind the pirq to an event channel, which gets mapped to a Linux irq and handled as usual. > Temporally ignoring what we have to do to work with Xen 3.4. I'm curious > if we could make the Xen dom0 irq case the same as the Xen domU case. > It is already; once the pirq is prepared, the process is the same in both cases. J
next prev parent reply other threads:[~2009-06-18 19:34 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-06-12 18:22 [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Jeremy Fitzhardinge 2009-06-12 18:22 ` Jeremy Fitzhardinge 2009-06-12 18:28 ` Alan Cox 2009-06-12 18:28 ` Alan Cox 2009-06-12 18:33 ` Jeremy Fitzhardinge 2009-06-12 18:33 ` Jeremy Fitzhardinge 2009-06-12 20:11 ` Cyrill Gorcunov 2009-06-15 2:01 ` Jeremy Fitzhardinge 2009-06-12 20:35 ` Eric W. Biederman 2009-06-12 20:35 ` Eric W. Biederman 2009-06-15 2:06 ` Jeremy Fitzhardinge 2009-06-15 10:47 ` Eric W. Biederman 2009-06-15 10:47 ` Eric W. Biederman 2009-06-15 20:49 ` Jeremy Fitzhardinge 2009-06-15 20:49 ` Jeremy Fitzhardinge 2009-06-15 21:58 ` Eric W. Biederman 2009-06-15 21:58 ` Eric W. Biederman 2009-06-16 19:38 ` Jeremy Fitzhardinge 2009-06-16 19:38 ` Jeremy Fitzhardinge 2009-06-17 5:10 ` Eric W. Biederman 2009-06-17 5:10 ` Eric W. Biederman 2009-06-17 12:02 ` Eric W. Biederman 2009-06-17 12:02 ` Eric W. Biederman 2009-06-17 17:32 ` Jeremy Fitzhardinge 2009-06-17 17:32 ` Jeremy Fitzhardinge 2009-06-18 2:58 ` Eric W. Biederman 2009-06-18 2:58 ` Eric W. Biederman 2009-06-18 19:34 ` Jeremy Fitzhardinge [this message] 2009-06-18 19:34 ` Jeremy Fitzhardinge 2009-06-18 20:28 ` Eric W. Biederman 2009-06-18 21:09 ` Jeremy Fitzhardinge 2009-06-18 21:09 ` Jeremy Fitzhardinge 2009-06-19 1:38 ` Eric W. Biederman 2009-06-19 1:38 ` Eric W. Biederman 2009-06-19 3:10 ` [Xen-devel] " Jiang, Yunhong 2009-06-19 3:10 ` Jiang, Yunhong 2009-06-18 12:26 ` Eric W. Biederman 2009-06-15 10:51 ` Eric W. Biederman 2009-06-15 10:51 ` Eric W. Biederman 2009-06-18 16:08 ` Len Brown 2009-06-18 19:14 ` Jeremy Fitzhardinge 2009-06-18 19:14 ` Jeremy Fitzhardinge 2009-06-18 19:27 ` Eric W. Biederman 2009-06-18 19:48 ` Jeremy Fitzhardinge 2009-06-18 19:48 ` Jeremy Fitzhardinge 2009-06-18 20:39 ` Eric W. Biederman 2009-06-18 22:33 ` Jeremy Fitzhardinge 2009-06-18 22:33 ` Jeremy Fitzhardinge 2009-06-19 2:42 ` Eric W. Biederman 2009-06-19 2:42 ` Eric W. Biederman 2009-06-19 19:58 ` Jeremy Fitzhardinge 2009-06-19 19:58 ` Jeremy Fitzhardinge 2009-06-19 23:44 ` [Xen-devel] " Nakajima, Jun 2009-06-19 23:44 ` Nakajima, Jun 2009-06-20 7:39 ` [Xen-devel] " Keir Fraser 2009-06-20 7:39 ` Keir Fraser 2009-06-20 8:21 ` [Xen-devel] " Eric W. Biederman 2009-06-20 8:21 ` Eric W. Biederman 2009-06-20 8:57 ` [Xen-devel] " Tian, Kevin 2009-06-20 8:57 ` Tian, Kevin 2009-06-20 10:22 ` [Xen-devel] " Keir Fraser 2009-06-20 10:22 ` Keir Fraser 2009-06-20 8:18 ` [Xen-devel] " Eric W. Biederman 2009-06-20 8:18 ` Eric W. Biederman 2009-06-19 5:32 ` Yinghai Lu 2009-06-19 5:32 ` Yinghai Lu 2009-06-19 5:50 ` Eric W. Biederman 2009-06-19 5:50 ` Eric W. Biederman 2009-06-19 7:52 ` [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause " Jan Beulich 2009-06-19 7:52 ` Jan Beulich 2009-06-19 8:16 ` [Xen-devel] " Eric W. Biederman 2009-06-19 8:16 ` Eric W. Biederman 2009-06-20 3:58 ` [Xen-devel] " Yinghai Lu 2009-06-20 3:58 ` Yinghai Lu 2009-06-20 5:40 ` [Xen-devel] " Eric W. Biederman 2009-06-20 5:40 ` Eric W. Biederman 2009-06-20 5:58 ` [Xen-devel] " Yinghai Lu 2009-06-20 5:58 ` Yinghai Lu 2009-06-18 22:51 ` [PATCH RFC] x86/acpi: don't ignore I/O APICs just because " Maciej W. Rozycki
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=4A3A96BC.1000302@goop.org \ --to=jeremy@goop.org \ --cc=ebiederm@xmission.com \ --cc=hpa@zytor.com \ --cc=keir.fraser@eu.citrix.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ --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: linkBe 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.