| Message ID | alpine.DEB.2.10.1606011118210.16603@sstabellini-ThinkPad-X260 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Stefano, Title: s/cannout/cannot/ I would add ACPI in the title to avoid people been scared by "we cannot route SPIs to DOM0" :). On 01/06/16 11:19, Stefano Stabellini wrote: > as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being > reverted. > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index ee35683..babc822 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -25,6 +25,8 @@ > #include <xen/irq.h> > #include <xen/sched.h> > #include <xen/perfc.h> > +#include <xen/iocap.h> > +#include <xen/acpi.h> > > #include <asm/current.h> > > @@ -342,9 +344,15 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n) > unsigned long flags; > int i = 0; > struct vcpu *v_target; > + struct domain *d = v->domain; > > while ( (i = find_next_bit(&mask, 32, i)) < 32 ) { > irq = i + (32 * n); > + /* Set the irq type and route it to guest only for SPI and Dom0 */ > + if( irq_access_permitted(d, irq) && is_hardware_domain(d) && > + ( irq >= 32 ) && ( !acpi_disabled ) ) > + gprintk(XENLOG_WARNING, "Routing SPIs to Dom0 on ACPI systems is unimplemented.\n"); The log will likely be spammed with this message (i.e everytime an IRQ is enabled). Should not we print this message only once? Either way: Acked-by: Julien Grall <julien.grall@arm.com> Regards,
On Wed, Jun 01, 2016 at 11:45:51AM +0100, Julien Grall wrote: > Hi Stefano, > > Title: s/cannout/cannot/ > > I would add ACPI in the title to avoid people been scared by "we cannot > route SPIs to DOM0" :). > > On 01/06/16 11:19, Stefano Stabellini wrote: > >as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being > >reverted. > >Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > > >diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > >index ee35683..babc822 100644 > >--- a/xen/arch/arm/vgic.c > >+++ b/xen/arch/arm/vgic.c > >@@ -25,6 +25,8 @@ > > #include <xen/irq.h> > > #include <xen/sched.h> > > #include <xen/perfc.h> > >+#include <xen/iocap.h> > >+#include <xen/acpi.h> > > > > #include <asm/current.h> > > > >@@ -342,9 +344,15 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n) > > unsigned long flags; > > int i = 0; > > struct vcpu *v_target; > >+ struct domain *d = v->domain; > > > > while ( (i = find_next_bit(&mask, 32, i)) < 32 ) { > > irq = i + (32 * n); > >+ /* Set the irq type and route it to guest only for SPI and Dom0 */ > >+ if( irq_access_permitted(d, irq) && is_hardware_domain(d) && > >+ ( irq >= 32 ) && ( !acpi_disabled ) ) > >+ gprintk(XENLOG_WARNING, "Routing SPIs to Dom0 on ACPI systems is unimplemented.\n"); > > The log will likely be spammed with this message (i.e everytime an IRQ is > enabled). Should not we print this message only once? > > Either way: > > Acked-by: Julien Grall <julien.grall@arm.com> > Release-acked-by: Wei Liu <wei.liu2@citrix.com> > Regards, > > -- > Julien Grall
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index ee35683..babc822 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -25,6 +25,8 @@ #include <xen/irq.h> #include <xen/sched.h> #include <xen/perfc.h> +#include <xen/iocap.h> +#include <xen/acpi.h> #include <asm/current.h> @@ -342,9 +344,15 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n) unsigned long flags; int i = 0; struct vcpu *v_target; + struct domain *d = v->domain; while ( (i = find_next_bit(&mask, 32, i)) < 32 ) { irq = i + (32 * n); + /* Set the irq type and route it to guest only for SPI and Dom0 */ + if( irq_access_permitted(d, irq) && is_hardware_domain(d) && + ( irq >= 32 ) && ( !acpi_disabled ) ) + gprintk(XENLOG_WARNING, "Routing SPIs to Dom0 on ACPI systems is unimplemented.\n"); + v_target = __vgic_get_target_vcpu(v, irq); p = irq_to_pending(v_target, irq); set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being reverted. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>