* [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
@ 2016-04-20 13:15 Stefano Stabellini
2016-04-21 9:08 ` Juergen Gross
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-04-20 13:15 UTC (permalink / raw)
To: boris.ostrovsky
Cc: sstabellini, linux-kernel, david.vrabel, jgross, xen-devel
b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index beac4df..349b8ce 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
#endif
__acpi_register_gsi = acpi_register_gsi_xen;
__acpi_unregister_gsi = NULL;
- /* Pre-allocate legacy irqs */
- for (irq = 0; irq < nr_legacy_irqs(); irq++) {
+ /*
+ * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
+ * because we don't have a PIC and thus nr_legacy_irqs() is zero.
+ */
+ for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
int trigger, polarity;
if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-20 13:15 [PATCH] xen/x86: actually allocate legacy interrupts on PV guests Stefano Stabellini
2016-04-21 9:08 ` Juergen Gross
@ 2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:30 ` Stefano Stabellini
2016-04-21 9:30 ` Stefano Stabellini
2016-04-21 11:02 ` [Xen-devel] " Olaf Hering
2016-04-21 11:02 ` Olaf Hering
3 siblings, 2 replies; 24+ messages in thread
From: Juergen Gross @ 2016-04-21 9:08 UTC (permalink / raw)
To: Stefano Stabellini, boris.ostrovsky; +Cc: linux-kernel, david.vrabel, xen-devel
On 20/04/16 15:15, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
Would you mind describing the resulting problem? With this commit
message I'm absolutely not capable to decide whether e.g. the other
use of nr_legacy_irqs() in pci_xen_initial_domain() is correct or
not.
Juergen
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index beac4df..349b8ce 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
> #endif
> __acpi_register_gsi = acpi_register_gsi_xen;
> __acpi_unregister_gsi = NULL;
> - /* Pre-allocate legacy irqs */
> - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
> + /*
> + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
> + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
> + */
> + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
> int trigger, polarity;
>
> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-20 13:15 [PATCH] xen/x86: actually allocate legacy interrupts on PV guests Stefano Stabellini
@ 2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:08 ` Juergen Gross
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: Juergen Gross @ 2016-04-21 9:08 UTC (permalink / raw)
To: Stefano Stabellini, boris.ostrovsky; +Cc: xen-devel, linux-kernel, david.vrabel
On 20/04/16 15:15, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
Would you mind describing the resulting problem? With this commit
message I'm absolutely not capable to decide whether e.g. the other
use of nr_legacy_irqs() in pci_xen_initial_domain() is correct or
not.
Juergen
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index beac4df..349b8ce 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
> #endif
> __acpi_register_gsi = acpi_register_gsi_xen;
> __acpi_unregister_gsi = NULL;
> - /* Pre-allocate legacy irqs */
> - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
> + /*
> + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
> + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
> + */
> + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
> int trigger, polarity;
>
> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:30 ` Stefano Stabellini
@ 2016-04-21 9:30 ` Stefano Stabellini
2016-04-27 5:02 ` Juergen Gross
2016-04-27 5:02 ` Juergen Gross
1 sibling, 2 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-04-21 9:30 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, boris.ostrovsky, linux-kernel, david.vrabel,
xen-devel
On Thu, 21 Apr 2016, Juergen Gross wrote:
> On 20/04/16 15:15, Stefano Stabellini wrote:
> > b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> > of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> > probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Would you mind describing the resulting problem?
This is a good question. The symptom is:
ata_piix: probe of 0000:00:01.1 failed with error -22
> With this commit message I'm absolutely not capable to decide whether
> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
> correct or not.
I looked at it but I couldn't really test that code because if I try to
change the number of ioapics in the system using the "noapic" command
line option (which actually changes the number if ioapics, not lapics),
I get an error from Linux saying that noapic is not supported when
running on Xen.
In my opinion having nr_legacy_irqs() calls in Xen code, which returns
0, is like playing with fire. I think it would be safer/saner to replace
them all with NR_IRQS_LEGACY, simply because reading the code one would
not expect that all those loops don't actually have any iterations.
However I didn't make the change because I couldn't test it properly.
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> >
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index beac4df..349b8ce 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
> > #endif
> > __acpi_register_gsi = acpi_register_gsi_xen;
> > __acpi_unregister_gsi = NULL;
> > - /* Pre-allocate legacy irqs */
> > - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
> > + /*
> > + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
> > + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
> > + */
> > + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
> > int trigger, polarity;
> >
> > if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
> >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-21 9:08 ` Juergen Gross
@ 2016-04-21 9:30 ` Stefano Stabellini
2016-04-21 9:30 ` Stefano Stabellini
1 sibling, 0 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-04-21 9:30 UTC (permalink / raw)
To: Juergen Gross
Cc: xen-devel, boris.ostrovsky, Stefano Stabellini, linux-kernel,
david.vrabel
On Thu, 21 Apr 2016, Juergen Gross wrote:
> On 20/04/16 15:15, Stefano Stabellini wrote:
> > b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> > of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> > probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Would you mind describing the resulting problem?
This is a good question. The symptom is:
ata_piix: probe of 0000:00:01.1 failed with error -22
> With this commit message I'm absolutely not capable to decide whether
> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
> correct or not.
I looked at it but I couldn't really test that code because if I try to
change the number of ioapics in the system using the "noapic" command
line option (which actually changes the number if ioapics, not lapics),
I get an error from Linux saying that noapic is not supported when
running on Xen.
In my opinion having nr_legacy_irqs() calls in Xen code, which returns
0, is like playing with fire. I think it would be safer/saner to replace
them all with NR_IRQS_LEGACY, simply because reading the code one would
not expect that all those loops don't actually have any iterations.
However I didn't make the change because I couldn't test it properly.
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> >
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index beac4df..349b8ce 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
> > #endif
> > __acpi_register_gsi = acpi_register_gsi_xen;
> > __acpi_unregister_gsi = NULL;
> > - /* Pre-allocate legacy irqs */
> > - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
> > + /*
> > + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
> > + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
> > + */
> > + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
> > int trigger, polarity;
> >
> > if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-20 13:15 [PATCH] xen/x86: actually allocate legacy interrupts on PV guests Stefano Stabellini
2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:08 ` Juergen Gross
@ 2016-04-21 11:02 ` Olaf Hering
2016-04-21 11:02 ` Olaf Hering
3 siblings, 0 replies; 24+ messages in thread
From: Olaf Hering @ 2016-04-21 11:02 UTC (permalink / raw)
To: Stefano Stabellini
Cc: boris.ostrovsky, jgross, xen-devel, linux-kernel, david.vrabel
On Wed, Apr 20, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Olaf Hering <olaf@aepfle.de>
Fixes my M9400 laptop (and should go to stable as well):
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg02624.html
Olaf
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-20 13:15 [PATCH] xen/x86: actually allocate legacy interrupts on PV guests Stefano Stabellini
` (2 preceding siblings ...)
2016-04-21 11:02 ` [Xen-devel] " Olaf Hering
@ 2016-04-21 11:02 ` Olaf Hering
3 siblings, 0 replies; 24+ messages in thread
From: Olaf Hering @ 2016-04-21 11:02 UTC (permalink / raw)
To: Stefano Stabellini
Cc: jgross, xen-devel, boris.ostrovsky, linux-kernel, david.vrabel
On Wed, Apr 20, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Olaf Hering <olaf@aepfle.de>
Fixes my M9400 laptop (and should go to stable as well):
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg02624.html
Olaf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-21 9:30 ` Stefano Stabellini
2016-04-27 5:02 ` Juergen Gross
@ 2016-04-27 5:02 ` Juergen Gross
2016-04-27 9:35 ` [Xen-devel] " David Vrabel
2016-04-27 9:35 ` David Vrabel
1 sibling, 2 replies; 24+ messages in thread
From: Juergen Gross @ 2016-04-27 5:02 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: boris.ostrovsky, linux-kernel, david.vrabel, xen-devel
On 21/04/16 11:30, Stefano Stabellini wrote:
> On Thu, 21 Apr 2016, Juergen Gross wrote:
>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>
>> Would you mind describing the resulting problem?
>
> This is a good question. The symptom is:
>
> ata_piix: probe of 0000:00:01.1 failed with error -22
>
>
>> With this commit message I'm absolutely not capable to decide whether
>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>> correct or not.
>
> I looked at it but I couldn't really test that code because if I try to
> change the number of ioapics in the system using the "noapic" command
> line option (which actually changes the number if ioapics, not lapics),
> I get an error from Linux saying that noapic is not supported when
> running on Xen.
>
> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
> 0, is like playing with fire. I think it would be safer/saner to replace
> them all with NR_IRQS_LEGACY, simply because reading the code one would
> not expect that all those loops don't actually have any iterations.
I'm quite sure you should change both uses of nr_legacy_irqs() in
pci_xen_initial_domain().
Looking at xen_pcifront_enable_irq() I'm not really sure what is the
correct thing to do.
Adding Konrad as he might have a better insight.
Juergen
>
> However I didn't make the change because I couldn't test it properly.
>
>
>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>>> index beac4df..349b8ce 100644
>>> --- a/arch/x86/pci/xen.c
>>> +++ b/arch/x86/pci/xen.c
>>> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
>>> #endif
>>> __acpi_register_gsi = acpi_register_gsi_xen;
>>> __acpi_unregister_gsi = NULL;
>>> - /* Pre-allocate legacy irqs */
>>> - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
>>> + /*
>>> + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
>>> + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
>>> + */
>>> + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
>>> int trigger, polarity;
>>>
>>> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
>>>
>>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-21 9:30 ` Stefano Stabellini
@ 2016-04-27 5:02 ` Juergen Gross
2016-04-27 5:02 ` Juergen Gross
1 sibling, 0 replies; 24+ messages in thread
From: Juergen Gross @ 2016-04-27 5:02 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, boris.ostrovsky, linux-kernel, david.vrabel
On 21/04/16 11:30, Stefano Stabellini wrote:
> On Thu, 21 Apr 2016, Juergen Gross wrote:
>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>
>> Would you mind describing the resulting problem?
>
> This is a good question. The symptom is:
>
> ata_piix: probe of 0000:00:01.1 failed with error -22
>
>
>> With this commit message I'm absolutely not capable to decide whether
>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>> correct or not.
>
> I looked at it but I couldn't really test that code because if I try to
> change the number of ioapics in the system using the "noapic" command
> line option (which actually changes the number if ioapics, not lapics),
> I get an error from Linux saying that noapic is not supported when
> running on Xen.
>
> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
> 0, is like playing with fire. I think it would be safer/saner to replace
> them all with NR_IRQS_LEGACY, simply because reading the code one would
> not expect that all those loops don't actually have any iterations.
I'm quite sure you should change both uses of nr_legacy_irqs() in
pci_xen_initial_domain().
Looking at xen_pcifront_enable_irq() I'm not really sure what is the
correct thing to do.
Adding Konrad as he might have a better insight.
Juergen
>
> However I didn't make the change because I couldn't test it properly.
>
>
>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>>> index beac4df..349b8ce 100644
>>> --- a/arch/x86/pci/xen.c
>>> +++ b/arch/x86/pci/xen.c
>>> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
>>> #endif
>>> __acpi_register_gsi = acpi_register_gsi_xen;
>>> __acpi_unregister_gsi = NULL;
>>> - /* Pre-allocate legacy irqs */
>>> - for (irq = 0; irq < nr_legacy_irqs(); irq++) {
>>> + /*
>>> + * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
>>> + * because we don't have a PIC and thus nr_legacy_irqs() is zero.
>>> + */
>>> + for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
>>> int trigger, polarity;
>>>
>>> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
>>>
>>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 5:02 ` Juergen Gross
@ 2016-04-27 9:35 ` David Vrabel
2016-04-27 13:38 ` Boris Ostrovsky
2016-04-27 9:35 ` David Vrabel
1 sibling, 1 reply; 24+ messages in thread
From: David Vrabel @ 2016-04-27 9:35 UTC (permalink / raw)
To: Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, boris.ostrovsky, linux-kernel, david.vrabel
On 27/04/16 06:02, Juergen Gross wrote:
> On 21/04/16 11:30, Stefano Stabellini wrote:
>> On Thu, 21 Apr 2016, Juergen Gross wrote:
>>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>>
>>> Would you mind describing the resulting problem?
>>
>> This is a good question. The symptom is:
>>
>> ata_piix: probe of 0000:00:01.1 failed with error -22
>>
>>
>>> With this commit message I'm absolutely not capable to decide whether
>>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>>> correct or not.
>>
>> I looked at it but I couldn't really test that code because if I try to
>> change the number of ioapics in the system using the "noapic" command
>> line option (which actually changes the number if ioapics, not lapics),
>> I get an error from Linux saying that noapic is not supported when
>> running on Xen.
>>
>> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
>> 0, is like playing with fire. I think it would be safer/saner to replace
>> them all with NR_IRQS_LEGACY, simply because reading the code one would
>> not expect that all those loops don't actually have any iterations.
>
> I'm quite sure you should change both uses of nr_legacy_irqs() in
> pci_xen_initial_domain().
>
> Looking at xen_pcifront_enable_irq() I'm not really sure what is the
> correct thing to do.
>
> Adding Konrad as he might have a better insight.
I wonder if it would be helpful to have a xen-specific #define like
XEN_NR_LEGACY_PIRQS or something, and document carefully what this means
and why it is != nr_legacy_irqs().
David
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 5:02 ` Juergen Gross
2016-04-27 9:35 ` [Xen-devel] " David Vrabel
@ 2016-04-27 9:35 ` David Vrabel
1 sibling, 0 replies; 24+ messages in thread
From: David Vrabel @ 2016-04-27 9:35 UTC (permalink / raw)
To: Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, boris.ostrovsky, linux-kernel, david.vrabel
On 27/04/16 06:02, Juergen Gross wrote:
> On 21/04/16 11:30, Stefano Stabellini wrote:
>> On Thu, 21 Apr 2016, Juergen Gross wrote:
>>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>>
>>> Would you mind describing the resulting problem?
>>
>> This is a good question. The symptom is:
>>
>> ata_piix: probe of 0000:00:01.1 failed with error -22
>>
>>
>>> With this commit message I'm absolutely not capable to decide whether
>>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>>> correct or not.
>>
>> I looked at it but I couldn't really test that code because if I try to
>> change the number of ioapics in the system using the "noapic" command
>> line option (which actually changes the number if ioapics, not lapics),
>> I get an error from Linux saying that noapic is not supported when
>> running on Xen.
>>
>> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
>> 0, is like playing with fire. I think it would be safer/saner to replace
>> them all with NR_IRQS_LEGACY, simply because reading the code one would
>> not expect that all those loops don't actually have any iterations.
>
> I'm quite sure you should change both uses of nr_legacy_irqs() in
> pci_xen_initial_domain().
>
> Looking at xen_pcifront_enable_irq() I'm not really sure what is the
> correct thing to do.
>
> Adding Konrad as he might have a better insight.
I wonder if it would be helpful to have a xen-specific #define like
XEN_NR_LEGACY_PIRQS or something, and document carefully what this means
and why it is != nr_legacy_irqs().
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 9:35 ` [Xen-devel] " David Vrabel
@ 2016-04-27 13:38 ` Boris Ostrovsky
0 siblings, 0 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-04-27 13:38 UTC (permalink / raw)
To: David Vrabel, Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 04/27/2016 05:35 AM, David Vrabel wrote:
> On 27/04/16 06:02, Juergen Gross wrote:
>> On 21/04/16 11:30, Stefano Stabellini wrote:
>>> On Thu, 21 Apr 2016, Juergen Gross wrote:
>>>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>>> Would you mind describing the resulting problem?
>>> This is a good question. The symptom is:
>>>
>>> ata_piix: probe of 0000:00:01.1 failed with error -22
>>>
>>>
>>>> With this commit message I'm absolutely not capable to decide whether
>>>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>>>> correct or not.
>>> I looked at it but I couldn't really test that code because if I try to
>>> change the number of ioapics in the system using the "noapic" command
>>> line option (which actually changes the number if ioapics, not lapics),
>>> I get an error from Linux saying that noapic is not supported when
>>> running on Xen.
>>>
>>> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
>>> 0, is like playing with fire. I think it would be safer/saner to replace
>>> them all with NR_IRQS_LEGACY, simply because reading the code one would
>>> not expect that all those loops don't actually have any iterations.
>> I'm quite sure you should change both uses of nr_legacy_irqs() in
>> pci_xen_initial_domain().
>>
>> Looking at xen_pcifront_enable_irq() I'm not really sure what is the
>> correct thing to do.
>>
>> Adding Konrad as he might have a better insight.
> I wonder if it would be helpful to have a xen-specific #define like
> XEN_NR_LEGACY_PIRQS or something, and document carefully what this means
> and why it is != nr_legacy_irqs().
int xen_nr_legacy_irqs()
{
if (xen_hvm_domain())
return nr_legacy_irqs();
if (xen_initial_domain())
return NR_IRQS_LEGACY;
return 0;
}
?
-boris
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
@ 2016-04-27 13:38 ` Boris Ostrovsky
0 siblings, 0 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-04-27 13:38 UTC (permalink / raw)
To: David Vrabel, Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 04/27/2016 05:35 AM, David Vrabel wrote:
> On 27/04/16 06:02, Juergen Gross wrote:
>> On 21/04/16 11:30, Stefano Stabellini wrote:
>>> On Thu, 21 Apr 2016, Juergen Gross wrote:
>>>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>>> Would you mind describing the resulting problem?
>>> This is a good question. The symptom is:
>>>
>>> ata_piix: probe of 0000:00:01.1 failed with error -22
>>>
>>>
>>>> With this commit message I'm absolutely not capable to decide whether
>>>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>>>> correct or not.
>>> I looked at it but I couldn't really test that code because if I try to
>>> change the number of ioapics in the system using the "noapic" command
>>> line option (which actually changes the number if ioapics, not lapics),
>>> I get an error from Linux saying that noapic is not supported when
>>> running on Xen.
>>>
>>> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
>>> 0, is like playing with fire. I think it would be safer/saner to replace
>>> them all with NR_IRQS_LEGACY, simply because reading the code one would
>>> not expect that all those loops don't actually have any iterations.
>> I'm quite sure you should change both uses of nr_legacy_irqs() in
>> pci_xen_initial_domain().
>>
>> Looking at xen_pcifront_enable_irq() I'm not really sure what is the
>> correct thing to do.
>>
>> Adding Konrad as he might have a better insight.
> I wonder if it would be helpful to have a xen-specific #define like
> XEN_NR_LEGACY_PIRQS or something, and document carefully what this means
> and why it is != nr_legacy_irqs().
int xen_nr_legacy_irqs()
{
if (xen_hvm_domain())
return nr_legacy_irqs();
if (xen_initial_domain())
return NR_IRQS_LEGACY;
return 0;
}
?
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 13:38 ` Boris Ostrovsky
(?)
(?)
@ 2016-04-27 13:40 ` David Vrabel
2016-04-27 14:03 ` Boris Ostrovsky
2016-04-27 14:03 ` [Xen-devel] " Boris Ostrovsky
-1 siblings, 2 replies; 24+ messages in thread
From: David Vrabel @ 2016-04-27 13:40 UTC (permalink / raw)
To: Boris Ostrovsky, Juergen Gross, Stefano Stabellini,
Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 27/04/16 14:38, Boris Ostrovsky wrote:
>
> int xen_nr_legacy_irqs()
> {
> if (xen_hvm_domain())
> return nr_legacy_irqs();
> if (xen_initial_domain())
> return NR_IRQS_LEGACY;
> return 0;
> }
Yeah, if that does the right thing...
David
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 13:38 ` Boris Ostrovsky
(?)
@ 2016-04-27 13:40 ` David Vrabel
-1 siblings, 0 replies; 24+ messages in thread
From: David Vrabel @ 2016-04-27 13:40 UTC (permalink / raw)
To: Boris Ostrovsky, Juergen Gross, Stefano Stabellini,
Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 27/04/16 14:38, Boris Ostrovsky wrote:
>
> int xen_nr_legacy_irqs()
> {
> if (xen_hvm_domain())
> return nr_legacy_irqs();
> if (xen_initial_domain())
> return NR_IRQS_LEGACY;
> return 0;
> }
Yeah, if that does the right thing...
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 13:40 ` [Xen-devel] " David Vrabel
2016-04-27 14:03 ` Boris Ostrovsky
@ 2016-04-27 14:03 ` Boris Ostrovsky
2016-05-16 11:23 ` Stefano Stabellini
2016-05-16 11:23 ` [Xen-devel] " Stefano Stabellini
1 sibling, 2 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-04-27 14:03 UTC (permalink / raw)
To: David Vrabel, Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 04/27/2016 09:40 AM, David Vrabel wrote:
> On 27/04/16 14:38, Boris Ostrovsky wrote:
>> int xen_nr_legacy_irqs()
>> {
>> if (xen_hvm_domain())
>> return nr_legacy_irqs();
>> if (xen_initial_domain())
>> return NR_IRQS_LEGACY;
>> return 0;
>> }
> Yeah, if that does the right thing...
I think it will break xen_allocate_irq_gsi() again, unless we check for
HVM domain explicitly. Which would be ugly.
-boris
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 13:40 ` [Xen-devel] " David Vrabel
@ 2016-04-27 14:03 ` Boris Ostrovsky
2016-04-27 14:03 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 0 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-04-27 14:03 UTC (permalink / raw)
To: David Vrabel, Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, linux-kernel
On 04/27/2016 09:40 AM, David Vrabel wrote:
> On 27/04/16 14:38, Boris Ostrovsky wrote:
>> int xen_nr_legacy_irqs()
>> {
>> if (xen_hvm_domain())
>> return nr_legacy_irqs();
>> if (xen_initial_domain())
>> return NR_IRQS_LEGACY;
>> return 0;
>> }
> Yeah, if that does the right thing...
I think it will break xen_allocate_irq_gsi() again, unless we check for
HVM domain explicitly. Which would be ugly.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 14:03 ` [Xen-devel] " Boris Ostrovsky
2016-05-16 11:23 ` Stefano Stabellini
@ 2016-05-16 11:23 ` Stefano Stabellini
2016-05-16 13:57 ` Boris Ostrovsky
2016-05-16 13:57 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 2 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-05-16 11:23 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: David Vrabel, Juergen Gross, Stefano Stabellini,
Konrad Rzeszutek Wilk, xen-devel, linux-kernel
On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> On 04/27/2016 09:40 AM, David Vrabel wrote:
> > On 27/04/16 14:38, Boris Ostrovsky wrote:
> > > int xen_nr_legacy_irqs()
> > > {
> > > if (xen_hvm_domain())
> > > return nr_legacy_irqs();
> > > if (xen_initial_domain())
> > > return NR_IRQS_LEGACY;
> > > return 0;
> > > }
> > Yeah, if that does the right thing...
>
> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> domain explicitly. Which would be ugly.
I guess we all forgot about this patch, in the meantime the merge window
has opened.
Should we go ahead with:
http://marc.info/?l=linux-kernel&m=146115812124261&w=2
?
It might not be complete, but it is certainly an improvement.
Otherwise, please submit proper patches ASAP. I don't think we want to
delay this fix until 4.8.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-04-27 14:03 ` [Xen-devel] " Boris Ostrovsky
@ 2016-05-16 11:23 ` Stefano Stabellini
2016-05-16 11:23 ` [Xen-devel] " Stefano Stabellini
1 sibling, 0 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-05-16 11:23 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Juergen Gross, Stefano Stabellini, linux-kernel, David Vrabel, xen-devel
On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> On 04/27/2016 09:40 AM, David Vrabel wrote:
> > On 27/04/16 14:38, Boris Ostrovsky wrote:
> > > int xen_nr_legacy_irqs()
> > > {
> > > if (xen_hvm_domain())
> > > return nr_legacy_irqs();
> > > if (xen_initial_domain())
> > > return NR_IRQS_LEGACY;
> > > return 0;
> > > }
> > Yeah, if that does the right thing...
>
> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> domain explicitly. Which would be ugly.
I guess we all forgot about this patch, in the meantime the merge window
has opened.
Should we go ahead with:
http://marc.info/?l=linux-kernel&m=146115812124261&w=2
?
It might not be complete, but it is certainly an improvement.
Otherwise, please submit proper patches ASAP. I don't think we want to
delay this fix until 4.8.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-05-16 11:23 ` [Xen-devel] " Stefano Stabellini
2016-05-16 13:57 ` Boris Ostrovsky
@ 2016-05-16 13:57 ` Boris Ostrovsky
2016-05-16 15:21 ` Stefano Stabellini
2016-05-16 15:21 ` Stefano Stabellini
1 sibling, 2 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-05-16 13:57 UTC (permalink / raw)
To: Stefano Stabellini
Cc: David Vrabel, Juergen Gross, Konrad Rzeszutek Wilk, xen-devel,
linux-kernel
On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
>> On 04/27/2016 09:40 AM, David Vrabel wrote:
>>> On 27/04/16 14:38, Boris Ostrovsky wrote:
>>>> int xen_nr_legacy_irqs()
>>>> {
>>>> if (xen_hvm_domain())
>>>> return nr_legacy_irqs();
>>>> if (xen_initial_domain())
>>>> return NR_IRQS_LEGACY;
>>>> return 0;
>>>> }
>>> Yeah, if that does the right thing...
>> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
>> domain explicitly. Which would be ugly.
> I guess we all forgot about this patch, in the meantime the merge window
> has opened.
>
> Should we go ahead with:
>
> http://marc.info/?l=linux-kernel&m=146115812124261&w=2
>
> ?
> It might not be complete, but it is certainly an improvement.
Yes, I think what you have there is the best option. What I suggested
above won't work and adding another check for HVM domain in
xen_allocate_irq_gsi() won't look good (although it does work).
It will need to go to stable as well (4.4+ ?)
-boris
>
> Otherwise, please submit proper patches ASAP. I don't think we want to
> delay this fix until 4.8.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-05-16 11:23 ` [Xen-devel] " Stefano Stabellini
@ 2016-05-16 13:57 ` Boris Ostrovsky
2016-05-16 13:57 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 0 replies; 24+ messages in thread
From: Boris Ostrovsky @ 2016-05-16 13:57 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Juergen Gross, xen-devel, David Vrabel, linux-kernel
On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
>> On 04/27/2016 09:40 AM, David Vrabel wrote:
>>> On 27/04/16 14:38, Boris Ostrovsky wrote:
>>>> int xen_nr_legacy_irqs()
>>>> {
>>>> if (xen_hvm_domain())
>>>> return nr_legacy_irqs();
>>>> if (xen_initial_domain())
>>>> return NR_IRQS_LEGACY;
>>>> return 0;
>>>> }
>>> Yeah, if that does the right thing...
>> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
>> domain explicitly. Which would be ugly.
> I guess we all forgot about this patch, in the meantime the merge window
> has opened.
>
> Should we go ahead with:
>
> http://marc.info/?l=linux-kernel&m=146115812124261&w=2
>
> ?
> It might not be complete, but it is certainly an improvement.
Yes, I think what you have there is the best option. What I suggested
above won't work and adding another check for HVM domain in
xen_allocate_irq_gsi() won't look good (although it does work).
It will need to go to stable as well (4.4+ ?)
-boris
>
> Otherwise, please submit proper patches ASAP. I don't think we want to
> delay this fix until 4.8.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-05-16 13:57 ` [Xen-devel] " Boris Ostrovsky
@ 2016-05-16 15:21 ` Stefano Stabellini
2016-05-16 15:21 ` Stefano Stabellini
1 sibling, 0 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-05-16 15:21 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Stefano Stabellini, David Vrabel, Juergen Gross,
Konrad Rzeszutek Wilk, xen-devel, linux-kernel
On Mon, 16 May 2016, Boris Ostrovsky wrote:
> On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> > On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> >> On 04/27/2016 09:40 AM, David Vrabel wrote:
> >>> On 27/04/16 14:38, Boris Ostrovsky wrote:
> >>>> int xen_nr_legacy_irqs()
> >>>> {
> >>>> if (xen_hvm_domain())
> >>>> return nr_legacy_irqs();
> >>>> if (xen_initial_domain())
> >>>> return NR_IRQS_LEGACY;
> >>>> return 0;
> >>>> }
> >>> Yeah, if that does the right thing...
> >> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> >> domain explicitly. Which would be ugly.
> > I guess we all forgot about this patch, in the meantime the merge window
> > has opened.
> >
> > Should we go ahead with:
> >
> > http://marc.info/?l=linux-kernel&m=146115812124261&w=2
> >
> > ?
> > It might not be complete, but it is certainly an improvement.
>
> Yes, I think what you have there is the best option. What I suggested
> above won't work and adding another check for HVM domain in
> xen_allocate_irq_gsi() won't look good (although it does work).
>
> It will need to go to stable as well (4.4+ ?)
All right, I'll commit it to for-linus-4.7 with
Cc: stable@vger.kernel.org
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
2016-05-16 13:57 ` [Xen-devel] " Boris Ostrovsky
2016-05-16 15:21 ` Stefano Stabellini
@ 2016-05-16 15:21 ` Stefano Stabellini
1 sibling, 0 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-05-16 15:21 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Juergen Gross, Stefano Stabellini, linux-kernel, David Vrabel, xen-devel
On Mon, 16 May 2016, Boris Ostrovsky wrote:
> On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> > On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> >> On 04/27/2016 09:40 AM, David Vrabel wrote:
> >>> On 27/04/16 14:38, Boris Ostrovsky wrote:
> >>>> int xen_nr_legacy_irqs()
> >>>> {
> >>>> if (xen_hvm_domain())
> >>>> return nr_legacy_irqs();
> >>>> if (xen_initial_domain())
> >>>> return NR_IRQS_LEGACY;
> >>>> return 0;
> >>>> }
> >>> Yeah, if that does the right thing...
> >> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> >> domain explicitly. Which would be ugly.
> > I guess we all forgot about this patch, in the meantime the merge window
> > has opened.
> >
> > Should we go ahead with:
> >
> > http://marc.info/?l=linux-kernel&m=146115812124261&w=2
> >
> > ?
> > It might not be complete, but it is certainly an improvement.
>
> Yes, I think what you have there is the best option. What I suggested
> above won't work and adding another check for HVM domain in
> xen_allocate_irq_gsi() won't look good (although it does work).
>
> It will need to go to stable as well (4.4+ ?)
All right, I'll commit it to for-linus-4.7 with
Cc: stable@vger.kernel.org
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
@ 2016-04-20 13:15 Stefano Stabellini
0 siblings, 0 replies; 24+ messages in thread
From: Stefano Stabellini @ 2016-04-20 13:15 UTC (permalink / raw)
To: boris.ostrovsky
Cc: jgross, xen-devel, sstabellini, linux-kernel, david.vrabel
b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index beac4df..349b8ce 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
#endif
__acpi_register_gsi = acpi_register_gsi_xen;
__acpi_unregister_gsi = NULL;
- /* Pre-allocate legacy irqs */
- for (irq = 0; irq < nr_legacy_irqs(); irq++) {
+ /*
+ * Pre-allocate the legacy IRQs. Use NR_LEGACY_IRQS here
+ * because we don't have a PIC and thus nr_legacy_irqs() is zero.
+ */
+ for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
int trigger, polarity;
if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-05-16 15:21 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-20 13:15 [PATCH] xen/x86: actually allocate legacy interrupts on PV guests Stefano Stabellini
2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:08 ` Juergen Gross
2016-04-21 9:30 ` Stefano Stabellini
2016-04-21 9:30 ` Stefano Stabellini
2016-04-27 5:02 ` Juergen Gross
2016-04-27 5:02 ` Juergen Gross
2016-04-27 9:35 ` [Xen-devel] " David Vrabel
2016-04-27 13:38 ` Boris Ostrovsky
2016-04-27 13:38 ` Boris Ostrovsky
2016-04-27 13:40 ` David Vrabel
2016-04-27 13:40 ` [Xen-devel] " David Vrabel
2016-04-27 14:03 ` Boris Ostrovsky
2016-04-27 14:03 ` [Xen-devel] " Boris Ostrovsky
2016-05-16 11:23 ` Stefano Stabellini
2016-05-16 11:23 ` [Xen-devel] " Stefano Stabellini
2016-05-16 13:57 ` Boris Ostrovsky
2016-05-16 13:57 ` [Xen-devel] " Boris Ostrovsky
2016-05-16 15:21 ` Stefano Stabellini
2016-05-16 15:21 ` Stefano Stabellini
2016-04-27 9:35 ` David Vrabel
2016-04-21 11:02 ` [Xen-devel] " Olaf Hering
2016-04-21 11:02 ` Olaf Hering
-- strict thread matches above, loose matches on Subject: below --
2016-04-20 13:15 Stefano Stabellini
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.