From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
Date: Wed, 27 Apr 2016 09:38:42 -0400 [thread overview]
Message-ID: <5720C0E2.8080904@oracle.com> (raw)
In-Reply-To: <572087E0.4030708@citrix.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests
Date: Wed, 27 Apr 2016 09:38:42 -0400 [thread overview]
Message-ID: <5720C0E2.8080904@oracle.com> (raw)
In-Reply-To: <572087E0.4030708@citrix.com>
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
next prev parent reply other threads:[~2016-04-27 13:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
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-27 5:02 ` Juergen Gross
2016-04-27 5:02 ` Juergen Gross
2016-04-27 9:35 ` David Vrabel
2016-04-27 9:35 ` [Xen-devel] " David Vrabel
2016-04-27 13:38 ` Boris Ostrovsky [this message]
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-21 9:30 ` Stefano Stabellini
2016-04-21 11:02 ` [Xen-devel] " Olaf Hering
2016-04-21 11:02 ` Olaf Hering
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=5720C0E2.8080904@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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.