From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jeremy@acsinet12.oracle.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH v3 02/10] xen: remap GSIs as pirqs when running as initial domain
Date: Tue, 19 Oct 2010 11:48:40 -0400 [thread overview]
Message-ID: <20101019154840.GA8066@dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1010191116480.2423@kaball-desktop>
On Tue, Oct 19, 2010 at 11:41:36AM +0100, Stefano Stabellini wrote:
> On Mon, 18 Oct 2010, Konrad Rzeszutek Wilk wrote:
> > On Tue, Oct 12, 2010 at 05:42:42PM +0100, Stefano Stabellini wrote:
> > > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > >
> > > Implement xen_register_gsi to setup the correct triggering and polarity
> > > properties of a gsi.
> > > Implement xen_register_pirq to register a particular gsi as pirq and
> > > receive interrupts as events.
> > > Call xen_setup_pirqs to register all the legacy ISA irqs as pirqs.
> > >
> > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > > arch/x86/include/asm/xen/pci.h | 7 ++
> > > arch/x86/pci/xen.c | 132 +++++++++++++++++++++++++++++++++++++++
> > > drivers/xen/events.c | 13 ++++
> > > include/xen/interface/physdev.h | 10 +++
> > > 4 files changed, 162 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> > > index f89a42a..2329b3e 100644
> > > --- a/arch/x86/include/asm/xen/pci.h
> > > +++ b/arch/x86/include/asm/xen/pci.h
> > > @@ -13,6 +13,13 @@ static inline int pci_xen_hvm_init(void)
> > > return -1;
> > > }
> > > #endif
> > > +#if defined(CONFIG_XEN_DOM0)
> > > +void __init xen_setup_pirqs(void);
> > > +#else
> > > +static inline void __init xen_setup_pirqs(void)
> > > +{
> > > +}
> > > +#endif
> > >
> > > #if defined(CONFIG_PCI_MSI)
> > > #if defined(CONFIG_PCI_XEN)
> > > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > > index fb20d05..5d87774 100644
> > > --- a/arch/x86/pci/xen.c
> > > +++ b/arch/x86/pci/xen.c
> > > @@ -262,3 +262,135 @@ int __init pci_xen_hvm_init(void)
> > > #endif
> > > return 0;
> > > }
> > > +
> > > +#ifdef CONFIG_XEN_DOM0
> > > +static int xen_register_pirq(u32 gsi, int triggering)
> > > +{
> > > + int rc, irq;
> > > + struct physdev_map_pirq map_irq;
> > > + int shareable = 0;
> > > + char *name;
> > > +
> > > + if (!xen_pv_domain())
> > > + return -1;
> > > +
> > > + if (triggering == ACPI_EDGE_SENSITIVE) {
> > > + shareable = 0;
> > > + name = "ioapic-edge";
> > > + } else {
> > > + shareable = 1;
> > > + name = "ioapic-level";
> > > + }
> > > +
> > > + irq = xen_allocate_pirq(gsi, shareable, name);
> > > +
> > > + printk(KERN_DEBUG "xen: --> irq=%d\n", irq);
> > > +
> > > + if (irq < 0)
> > > + goto out;
> > > +
> > > + map_irq.domid = DOMID_SELF;
> > > + map_irq.type = MAP_PIRQ_TYPE_GSI;
> > > + map_irq.index = gsi;
> > > + map_irq.pirq = irq;
> > > +
> > > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq);
> > > + if (rc) {
> > > + printk(KERN_WARNING "xen map irq failed %d\n", rc);
> > > + return -1;
> > > + }
> > > +
> > > +out:
> > > + return irq;
> > > +}
> > > +
> > > +static int xen_register_gsi(u32 gsi, int triggering, int polarity)
> > > +{
> > > + int rc, irq;
> > > + struct physdev_setup_gsi setup_gsi;
> > > +
> > > + if (!xen_pv_domain())
> > > + return -1;
> > > +
> > > + printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
> > > + gsi, triggering, polarity);
> > > +
> > > + irq = xen_register_pirq(gsi, triggering);
> > > +
> > > + setup_gsi.gsi = gsi;
> > > + setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
> > > + setup_gsi.polarity = (polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
> > > +
> > > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_setup_gsi, &setup_gsi);
> > > + if (rc == -EEXIST)
> > > + printk(KERN_INFO "Already setup the GSI :%d\n", gsi);
> > > + else if (rc) {
> > > + printk(KERN_ERR "Failed to setup GSI :%d, err_code:%d\n",
> > > + gsi, rc);
> > > + }
> > > +
> > > + return irq;
> > > +}
> > > +
> > > +static __init void xen_setup_acpi_sci(void)
> > > +{
> > > + int rc;
> > > + int trigger, polarity;
> > > + int gsi = acpi_sci_override_gsi;
> > > +
> > > + if (!gsi)
> > > + return;
> >
> > Should this be 'if (gsi >= 0)' ? I haven't seen any machine
> > with the GSI at IRQ 0, but perhaps it would be possible?
> >
>
> The test is correct as it is because it is meant to check if the
> acpi_sci_override_gsi has been set correctly and by default is 0.
> A similar test is done in
> arch/x86/kernel/acpi/boot.c:acpi_parse_madt_ioapic_entries.
ok.
>
>
> > > +
> > > + rc = acpi_get_override_irq(gsi, &trigger, &polarity);
> > > + if (rc)
> > > + return;
> >
> > We don't want to report the error? Say a printk?
> >
>
> good idea, I'll add one.
Thank you.
>
> > > + trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> > > + polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> > > +
> > > + printk("xen: sci override: global_irq=%d trigger=%d polarity=%d\n",
> > > + gsi, trigger, polarity);
> > > +
> > > + gsi = xen_register_gsi(gsi, trigger, polarity);
> > > + printk("xen: acpi sci %d\n", gsi);
> >
> > KERN_INFO ?
>
> ok
Danke.
>
> > > +
> > > + return;
> > > +}
> > > +
> > > +static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
> > > + int trigger, int polarity)
> > > +{
> > > + return xen_register_gsi(gsi, trigger, polarity);
> > > +}
> > > +
> > > +static int __init pci_xen_initial_domain(void)
> > > +{
> > > + xen_setup_acpi_sci();
> > > + __acpi_register_gsi = acpi_register_gsi_xen;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +void __init xen_setup_pirqs(void)
> > > +{
> > > + int irq;
> > > +
> > > + pci_xen_initial_domain();
> > > +
> > > + if (0 == nr_ioapics) {
> >
> > This function is only called for the Dom0 case, so under
> > what conditions would we have a machine with zero IO APICs?
> >
> > And do we actually support machines with no IO APICs?
> > (would Xen run under such ancient hardware?)
>
> I don't know about real hardware but during the development of the PV on
> HVM series I was able to boot a PV on HVM guest using the nr_ioapics==0
> code path successfully several times.
> And you never know what the future may bring :)
True.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
Jeremy@acsinet12.oracle.com,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH v3 02/10] xen: remap GSIs as pirqs when running as initial domain
Date: Tue, 19 Oct 2010 11:48:40 -0400 [thread overview]
Message-ID: <20101019154840.GA8066@dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1010191116480.2423@kaball-desktop>
On Tue, Oct 19, 2010 at 11:41:36AM +0100, Stefano Stabellini wrote:
> On Mon, 18 Oct 2010, Konrad Rzeszutek Wilk wrote:
> > On Tue, Oct 12, 2010 at 05:42:42PM +0100, Stefano Stabellini wrote:
> > > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > >
> > > Implement xen_register_gsi to setup the correct triggering and polarity
> > > properties of a gsi.
> > > Implement xen_register_pirq to register a particular gsi as pirq and
> > > receive interrupts as events.
> > > Call xen_setup_pirqs to register all the legacy ISA irqs as pirqs.
> > >
> > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > > arch/x86/include/asm/xen/pci.h | 7 ++
> > > arch/x86/pci/xen.c | 132 +++++++++++++++++++++++++++++++++++++++
> > > drivers/xen/events.c | 13 ++++
> > > include/xen/interface/physdev.h | 10 +++
> > > 4 files changed, 162 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> > > index f89a42a..2329b3e 100644
> > > --- a/arch/x86/include/asm/xen/pci.h
> > > +++ b/arch/x86/include/asm/xen/pci.h
> > > @@ -13,6 +13,13 @@ static inline int pci_xen_hvm_init(void)
> > > return -1;
> > > }
> > > #endif
> > > +#if defined(CONFIG_XEN_DOM0)
> > > +void __init xen_setup_pirqs(void);
> > > +#else
> > > +static inline void __init xen_setup_pirqs(void)
> > > +{
> > > +}
> > > +#endif
> > >
> > > #if defined(CONFIG_PCI_MSI)
> > > #if defined(CONFIG_PCI_XEN)
> > > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > > index fb20d05..5d87774 100644
> > > --- a/arch/x86/pci/xen.c
> > > +++ b/arch/x86/pci/xen.c
> > > @@ -262,3 +262,135 @@ int __init pci_xen_hvm_init(void)
> > > #endif
> > > return 0;
> > > }
> > > +
> > > +#ifdef CONFIG_XEN_DOM0
> > > +static int xen_register_pirq(u32 gsi, int triggering)
> > > +{
> > > + int rc, irq;
> > > + struct physdev_map_pirq map_irq;
> > > + int shareable = 0;
> > > + char *name;
> > > +
> > > + if (!xen_pv_domain())
> > > + return -1;
> > > +
> > > + if (triggering == ACPI_EDGE_SENSITIVE) {
> > > + shareable = 0;
> > > + name = "ioapic-edge";
> > > + } else {
> > > + shareable = 1;
> > > + name = "ioapic-level";
> > > + }
> > > +
> > > + irq = xen_allocate_pirq(gsi, shareable, name);
> > > +
> > > + printk(KERN_DEBUG "xen: --> irq=%d\n", irq);
> > > +
> > > + if (irq < 0)
> > > + goto out;
> > > +
> > > + map_irq.domid = DOMID_SELF;
> > > + map_irq.type = MAP_PIRQ_TYPE_GSI;
> > > + map_irq.index = gsi;
> > > + map_irq.pirq = irq;
> > > +
> > > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq);
> > > + if (rc) {
> > > + printk(KERN_WARNING "xen map irq failed %d\n", rc);
> > > + return -1;
> > > + }
> > > +
> > > +out:
> > > + return irq;
> > > +}
> > > +
> > > +static int xen_register_gsi(u32 gsi, int triggering, int polarity)
> > > +{
> > > + int rc, irq;
> > > + struct physdev_setup_gsi setup_gsi;
> > > +
> > > + if (!xen_pv_domain())
> > > + return -1;
> > > +
> > > + printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
> > > + gsi, triggering, polarity);
> > > +
> > > + irq = xen_register_pirq(gsi, triggering);
> > > +
> > > + setup_gsi.gsi = gsi;
> > > + setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
> > > + setup_gsi.polarity = (polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
> > > +
> > > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_setup_gsi, &setup_gsi);
> > > + if (rc == -EEXIST)
> > > + printk(KERN_INFO "Already setup the GSI :%d\n", gsi);
> > > + else if (rc) {
> > > + printk(KERN_ERR "Failed to setup GSI :%d, err_code:%d\n",
> > > + gsi, rc);
> > > + }
> > > +
> > > + return irq;
> > > +}
> > > +
> > > +static __init void xen_setup_acpi_sci(void)
> > > +{
> > > + int rc;
> > > + int trigger, polarity;
> > > + int gsi = acpi_sci_override_gsi;
> > > +
> > > + if (!gsi)
> > > + return;
> >
> > Should this be 'if (gsi >= 0)' ? I haven't seen any machine
> > with the GSI at IRQ 0, but perhaps it would be possible?
> >
>
> The test is correct as it is because it is meant to check if the
> acpi_sci_override_gsi has been set correctly and by default is 0.
> A similar test is done in
> arch/x86/kernel/acpi/boot.c:acpi_parse_madt_ioapic_entries.
ok.
>
>
> > > +
> > > + rc = acpi_get_override_irq(gsi, &trigger, &polarity);
> > > + if (rc)
> > > + return;
> >
> > We don't want to report the error? Say a printk?
> >
>
> good idea, I'll add one.
Thank you.
>
> > > + trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> > > + polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> > > +
> > > + printk("xen: sci override: global_irq=%d trigger=%d polarity=%d\n",
> > > + gsi, trigger, polarity);
> > > +
> > > + gsi = xen_register_gsi(gsi, trigger, polarity);
> > > + printk("xen: acpi sci %d\n", gsi);
> >
> > KERN_INFO ?
>
> ok
Danke.
>
> > > +
> > > + return;
> > > +}
> > > +
> > > +static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
> > > + int trigger, int polarity)
> > > +{
> > > + return xen_register_gsi(gsi, trigger, polarity);
> > > +}
> > > +
> > > +static int __init pci_xen_initial_domain(void)
> > > +{
> > > + xen_setup_acpi_sci();
> > > + __acpi_register_gsi = acpi_register_gsi_xen;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +void __init xen_setup_pirqs(void)
> > > +{
> > > + int irq;
> > > +
> > > + pci_xen_initial_domain();
> > > +
> > > + if (0 == nr_ioapics) {
> >
> > This function is only called for the Dom0 case, so under
> > what conditions would we have a machine with zero IO APICs?
> >
> > And do we actually support machines with no IO APICs?
> > (would Xen run under such ancient hardware?)
>
> I don't know about real hardware but during the development of the PV on
> HVM series I was able to boot a PV on HVM guest using the nr_ioapics==0
> code path successfully several times.
> And you never know what the future may bring :)
True.
next prev parent reply other threads:[~2010-10-19 15:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 16:41 [PATCH v3 00/10] xen: initial domain support Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 01/10] xen: introduce XEN_DOM0 as a silent option Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 02/10] xen: remap GSIs as pirqs when running as initial domain Stefano Stabellini
2010-10-18 15:41 ` Konrad Rzeszutek Wilk
2010-10-18 15:41 ` Konrad Rzeszutek Wilk
2010-10-19 10:41 ` Stefano Stabellini
2010-10-19 10:41 ` Stefano Stabellini
2010-10-19 15:48 ` Konrad Rzeszutek Wilk [this message]
2010-10-19 15:48 ` Konrad Rzeszutek Wilk
2010-10-12 16:42 ` [PATCH v3 03/10] xen: remap MSIs into " Stefano Stabellini
2010-10-18 15:46 ` Konrad Rzeszutek Wilk
2010-10-18 15:46 ` Konrad Rzeszutek Wilk
2010-10-19 10:43 ` Stefano Stabellini
2010-10-19 10:43 ` Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 04/10] xen: map a dummy page for local apic and ioapic in xen_set_fixmap Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 05/10] xen: use vcpu_ops to setup cpu masks Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 06/10] xen: Initialize xenbus for dom0 Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 07/10] xen: add the direct mapping area for ISA bus access Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 08/10] xen: use host E820 map for dom0 Stefano Stabellini
2010-10-18 15:54 ` Konrad Rzeszutek Wilk
2010-10-18 15:54 ` Konrad Rzeszutek Wilk
2010-10-19 10:49 ` Stefano Stabellini
2010-10-19 10:49 ` Stefano Stabellini
2010-10-20 17:05 ` [Xen-devel] " Jeremy Fitzhardinge
2010-10-12 16:42 ` [PATCH v3 09/10] xen: make hvc_xen console work " Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 10/10] xen: mask the MTRR feature from the cpuid Stefano Stabellini
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=20101019154840.GA8066@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=Jeremy@acsinet12.oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.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.