[PATCH] have architectures specify the number of PIRQs a hardware domain gets

[PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 4643 bytes --]

The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is meant to be an alternative proposal to David's:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00421.html 

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -596,13 +596,14 @@ Force or disable use of EFI runtime serv
 ### extra\_guest\_irqs
 > `= [<domU number>][,<dom0 number>]`
 
-> Default: `32,256`
+> Default: `32,<variable>`
 
 Change the number of PIRQs available for guests.  The optional first number is
 common for all domUs, while the optional second number (preceded by a comma)
 is for dom0.  Changing the setting for domU has no impact on dom0 and vice
 versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=,512`
+`extra_guest_irqs=,512`.  The default value for Dom0 and an eventual separate
+hardware domain is architecture dependent.
 
 ### flask\_enabled
 > `= <integer>`
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -101,7 +101,7 @@ static void __init parse_dom0_max_vcpus(
 }
 custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+unsigned int __init dom0_max_vcpus(void)
 {
     unsigned max_vcpus;
 
@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(str
     if ( max_vcpus > MAX_VIRT_CPUS )
         max_vcpus = MAX_VIRT_CPUS;
 
+    return max_vcpus;
+}
+
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+{
+    unsigned int max_vcpus = dom0_max_vcpus();
+
     dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -33,6 +33,7 @@
 #include <asm/smp.h>
 #include <asm/desc.h>
 #include <asm/msi.h>
+#include <asm/setup.h>
 #include <mach_apic.h>
 #include <io_ports.h>
 #include <public/physdev.h>
@@ -2606,3 +2607,14 @@ void __init init_ioapic_mappings(void)
            nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
 }
 
+unsigned int arch_hwdom_irqs(domid_t domid)
+{
+    unsigned int n = fls(num_present_cpus());
+
+    if ( !domid )
+        n = min(n, dom0_max_vcpus());
+    n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);
+    printk("Dom%d has maximum %u PIRQs\n", domid, n);
+
+    return n;
+}
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,14 @@ static int late_hwdom_init(struct domain
 #endif
 }
 
-static unsigned int __read_mostly extra_dom0_irqs = 256;
+static unsigned int __read_mostly extra_hwdom_irqs;
 static unsigned int __read_mostly extra_domU_irqs = 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs = simple_strtoul(s, &s, 0);
     if ( *s == ',' && isdigit(*++s) )
-        extra_dom0_irqs = simple_strtoul(s, &s, 0);
+        extra_hwdom_irqs = simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
@@ -326,7 +326,8 @@ struct domain *domain_create(
         if ( !is_hardware_domain(d) )
             d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
         else
-            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
+            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
+                                           : arch_hwdom_irqs(domid);
         if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs = nr_irqs;
 
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -21,10 +21,10 @@ struct arch_irq_desc {
 
 #define NR_LOCAL_IRQS	32
 #define NR_IRQS		1024
-#define nr_irqs NR_IRQS
 
 #define nr_irqs NR_IRQS
 #define nr_static_irqs NR_IRQS
+#define arch_hwdom_irqs(domid) NR_IRQS
 
 struct irq_desc;
 struct irqaction;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -35,6 +35,8 @@ int construct_dom0(
 unsigned long initial_images_nrpages(void);
 void discard_initial_images(void);
 
+unsigned int dom0_max_vcpus(void);
+
 int xen_in_range(unsigned long mfn);
 
 void microcode_grab_module(
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u
 
 unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *);
 
+#ifndef arch_hwdom_irqs
+unsigned int arch_hwdom_irqs(domid_t);
+#endif
+
 #endif /* __XEN_IRQ_H__ */



[-- Attachment #2: x86-bump-extra-Dom0-IRQs.patch --]
[-- Type: text/plain, Size: 4711 bytes --]

have architectures specify the number of PIRQs a hardware domain gets

The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is meant to be an alternative proposal to David's:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00421.html

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -596,13 +596,14 @@ Force or disable use of EFI runtime serv
 ### extra\_guest\_irqs
 > `= [<domU number>][,<dom0 number>]`
 
-> Default: `32,256`
+> Default: `32,<variable>`
 
 Change the number of PIRQs available for guests.  The optional first number is
 common for all domUs, while the optional second number (preceded by a comma)
 is for dom0.  Changing the setting for domU has no impact on dom0 and vice
 versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=,512`
+`extra_guest_irqs=,512`.  The default value for Dom0 and an eventual separate
+hardware domain is architecture dependent.
 
 ### flask\_enabled
 > `= <integer>`
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -101,7 +101,7 @@ static void __init parse_dom0_max_vcpus(
 }
 custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+unsigned int __init dom0_max_vcpus(void)
 {
     unsigned max_vcpus;
 
@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(str
     if ( max_vcpus > MAX_VIRT_CPUS )
         max_vcpus = MAX_VIRT_CPUS;
 
+    return max_vcpus;
+}
+
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+{
+    unsigned int max_vcpus = dom0_max_vcpus();
+
     dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -33,6 +33,7 @@
 #include <asm/smp.h>
 #include <asm/desc.h>
 #include <asm/msi.h>
+#include <asm/setup.h>
 #include <mach_apic.h>
 #include <io_ports.h>
 #include <public/physdev.h>
@@ -2606,3 +2607,14 @@ void __init init_ioapic_mappings(void)
            nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
 }
 
+unsigned int arch_hwdom_irqs(domid_t domid)
+{
+    unsigned int n = fls(num_present_cpus());
+
+    if ( !domid )
+        n = min(n, dom0_max_vcpus());
+    n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);
+    printk("Dom%d has maximum %u PIRQs\n", domid, n);
+
+    return n;
+}
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,14 @@ static int late_hwdom_init(struct domain
 #endif
 }
 
-static unsigned int __read_mostly extra_dom0_irqs = 256;
+static unsigned int __read_mostly extra_hwdom_irqs;
 static unsigned int __read_mostly extra_domU_irqs = 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs = simple_strtoul(s, &s, 0);
     if ( *s == ',' && isdigit(*++s) )
-        extra_dom0_irqs = simple_strtoul(s, &s, 0);
+        extra_hwdom_irqs = simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
@@ -326,7 +326,8 @@ struct domain *domain_create(
         if ( !is_hardware_domain(d) )
             d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
         else
-            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
+            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
+                                           : arch_hwdom_irqs(domid);
         if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs = nr_irqs;
 
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -21,10 +21,10 @@ struct arch_irq_desc {
 
 #define NR_LOCAL_IRQS	32
 #define NR_IRQS		1024
-#define nr_irqs NR_IRQS
 
 #define nr_irqs NR_IRQS
 #define nr_static_irqs NR_IRQS
+#define arch_hwdom_irqs(domid) NR_IRQS
 
 struct irq_desc;
 struct irqaction;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -35,6 +35,8 @@ int construct_dom0(
 unsigned long initial_images_nrpages(void);
 void discard_initial_images(void);
 
+unsigned int dom0_max_vcpus(void);
+
 int xen_in_range(unsigned long mfn);
 
 void microcode_grab_module(
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u
 
 unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *);
 
+#ifndef arch_hwdom_irqs
+unsigned int arch_hwdom_irqs(domid_t);
+#endif
+
 #endif /* __XEN_IRQ_H__ */

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Ian Campbell]

On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>  #define nr_static_irqs NR_IRQS
> +#define arch_hwdom_irqs(domid) NR_IRQS

FWIW gic_number_lines() is the ARM equivalent of getting the number of
GSIs.

*BUT* we don't actually use pirqs on ARM (everything goes via the
virtualised interrupt controller). So maybe we should be setting
nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
from an ARM person, so I'm fine with you making this NR_IRQS in the
meantime.

Ian.

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Julien Grall]

Hi,

On 05/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

As we already know that PIRQ is not used on ARM, it would make sense to
use directly in this patch 0.

Regards,

-- 
Julien Grall

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Ian Campbell]

On Fri, 2014-12-05 at 14:36 +0000, Julien Grall wrote:
> Hi,
> 
> On 05/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> As we already know that PIRQ is not used on ARM, it would make sense to
> use directly in this patch 0.

Are you offering to give a tested-by if Jan posts such a patch?

Ian.

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

>>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

Considering Julien also asking for this, I don't mind changing this to
zero for ARM. Just let me know which way I can get this ack-ed.

Jan

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[David Vrabel]

On 05/12/14 13:51, Jan Beulich wrote:
> The current value of nr_static_irqs + 256 is often too small for larger
> systems. Make it dependent on CPU count and number of IO-APIC pins on
> x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I obviously prefer the simpler version that removes an unnecessary
configuration option. But in the sense that this resolves the immediate
problem at least for the short to medium term:

Acked-by: David Vrabel <david.vrabel@citrix.com>

> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
> +                                           : arch_hwdom_irqs(domid);

This means if the user asks for 0 extra (by the command line) for hwdoms
they get the default which non-obvious.

David

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Ian Campbell]

On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> Considering Julien also asking for this, I don't mind changing this to
> zero for ARM. Just let me know which way I can get this ack-ed.

If you are happy to provide a version using zero and Julien wants to
provide a tested-by then I'm fine with going that way.

I'm not happy taking that change untested though, and I don't expect you
to test it.

Ian.

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

>>> On 05.12.14 at 15:48, <david.vrabel@citrix.com> wrote:
> On 05/12/14 13:51, Jan Beulich wrote:
>> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
>> +                                           : arch_hwdom_irqs(domid);
> 
> This means if the user asks for 0 extra (by the command line) for hwdoms
> they get the default which non-obvious.

I can certainly add another sentence saying so to the documentation.

Jan

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Julien Grall]

On 05/12/14 14:42, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:36 +0000, Julien Grall wrote:
>> Hi,
>>
>> On 05/12/14 14:27, Ian Campbell wrote:
>>> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>>>  #define nr_static_irqs NR_IRQS
>>>> +#define arch_hwdom_irqs(domid) NR_IRQS
>>>
>>> FWIW gic_number_lines() is the ARM equivalent of getting the number of
>>> GSIs.
>>>
>>> *BUT* we don't actually use pirqs on ARM (everything goes via the
>>> virtualised interrupt controller). So maybe we should be setting
>>> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>>> from an ARM person, so I'm fine with you making this NR_IRQS in the
>>> meantime.
>>
>> As we already know that PIRQ is not used on ARM, it would make sense to
>> use directly in this patch 0.
> 
> Are you offering to give a tested-by if Jan posts such a patch?

nr_pirqs is used in 2 different place (without counting this setting):
	- event channel => We don't care on ARM as alloc_pirq_struct is
returning NULL
	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
AFAIU the pirq number is different on each domain. But we use it to
check permission on both domain. Shouldn't we translate the pirq to irq
for the current->domain?

Regards,

-- 
Julien Grall

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> AFAIU the pirq number is different on each domain. But we use it to
> check permission on both domain. Shouldn't we translate the pirq to irq
> for the current->domain?

Indeed, see also
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Jan

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Julien Grall]

On 05/12/14 15:42, Jan Beulich wrote:
>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>> AFAIU the pirq number is different on each domain. But we use it to
>> check permission on both domain. Shouldn't we translate the pirq to irq
>> for the current->domain?
> 
> Indeed, see also
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Do you plan to send a patch to resolve this problem?

Regards,

-- 
Julien Grall

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

>>> On 05.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> On 05/12/14 15:42, Jan Beulich wrote:
>>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>>> AFAIU the pirq number is different on each domain. But we use it to
>>> check permission on both domain. Shouldn't we translate the pirq to irq
>>> for the current->domain?
>> 
>> Indeed, see also
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> 
> Do you plan to send a patch to resolve this problem?

So far I assumed Stefano would, as he was running into an issue
which iirc fixing this would help.

Jan

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Stefano Stabellini]

On Fri, 5 Dec 2014, Jan Beulich wrote:
> >>> On 05.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> > On 05/12/14 15:42, Jan Beulich wrote:
> >>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> >>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> >>> AFAIU the pirq number is different on each domain. But we use it to
> >>> check permission on both domain. Shouldn't we translate the pirq to irq
> >>> for the current->domain?
> >> 
> >> Indeed, see also
> >> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> > 
> > Do you plan to send a patch to resolve this problem?
> 
> So far I assumed Stefano would, as he was running into an issue
> which iirc fixing this would help.

I was only interested in fixing a bug for the 4.5 release, this work is
not suitable for 4.5 and I don't know if I'll do it for 4.6.

Regarding the original bug I was trying to fix, I think the original
patch should go in as is:

http://marc.info/?i=alpine.DEB.2.02.1412011852390.14135%40kaball.uk.xensource.com

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Ian Campbell]

On Fri, 2014-12-05 at 14:51 +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> > >>  #define nr_static_irqs NR_IRQS
> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > > 
> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > > GSIs.
> > > 
> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > > virtualised interrupt controller). So maybe we should be setting
> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > > meantime.
> > 
> > Considering Julien also asking for this, I don't mind changing this to
> > zero for ARM. Just let me know which way I can get this ack-ed.
> 
> If you are happy to provide a version using zero and Julien wants to
> provide a tested-by then I'm fine with going that way.

Seems like things were more complex than Julien expected here, so I
think changing to zero would be a mistake at this point.

AIUI this patch results in no functional change for ARM, in that dom0
previously saw:
        d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
where nr_static_irqs == NR_IRQS on ARM where now it sees:

When extra_dom0_irqs > 0
        nr_static_irqs + extra_dom0_irqs
which is the same as before. Or when extra_dom0_irqs:
        arch_hwdom_irqs(domid);
==   NR_IRQS
==   nr_static_irqs + 0
i.e. no change.

Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
to 1020 IRQs in h/w anyway), so I don't consider that a problem.

If that's all correct then: 
        Acked-by: Ian Campbell <ian.campbell@citrix.com>

Also Ack with my REST maintainer hat on for the general principal/common
code.

Ian.

Re: [PATCH] have architectures specify the number of PIRQs a hardware domain gets

[Jan Beulich]

>>> On 11.12.14 at 13:07, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-12-05 at 14:51 +0000, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
>> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
>> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>> > >>  #define nr_static_irqs NR_IRQS
>> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
>> > > 
>> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
>> > > GSIs.
>> > > 
>> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
>> > > virtualised interrupt controller). So maybe we should be setting
>> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
>> > > meantime.
>> > 
>> > Considering Julien also asking for this, I don't mind changing this to
>> > zero for ARM. Just let me know which way I can get this ack-ed.
>> 
>> If you are happy to provide a version using zero and Julien wants to
>> provide a tested-by then I'm fine with going that way.
> 
> Seems like things were more complex than Julien expected here, so I
> think changing to zero would be a mistake at this point.
> 
> AIUI this patch results in no functional change for ARM, in that dom0
> previously saw:
>         d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> where nr_static_irqs == NR_IRQS on ARM where now it sees:
> 
> When extra_dom0_irqs > 0
>         nr_static_irqs + extra_dom0_irqs
> which is the same as before. Or when extra_dom0_irqs:
>         arch_hwdom_irqs(domid);
> ==   NR_IRQS
> ==   nr_static_irqs + 0
> i.e. no change.
> 
> Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
> don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
> to 1020 IRQs in h/w anyway), so I don't consider that a problem.
> 
> If that's all correct then: 

It is.

>         Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Also Ack with my REST maintainer hat on for the general principal/common
> code.

Thanks!

Jan