Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752610AbcD0FCP (ORCPT ); Wed, 27 Apr 2016 01:02:15 -0400 Received: from mx2.suse.de ([195.135.220.15]:55230 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbcD0FCO (ORCPT ); Wed, 27 Apr 2016 01:02:14 -0400 Subject: Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests To: Stefano Stabellini , Konrad Rzeszutek Wilk References: <57189880.6030102@suse.com> Cc: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org, david.vrabel@citrix.com, xen-devel@lists.xenproject.org From: Juergen Gross Message-ID: <572047D3.1000002@suse.com> Date: Wed, 27 Apr 2016 07:02:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2386 Lines: 68 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 >>> >>> 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) >>> >> > >