Re: [Xen-devel] default value of extra_dom0_irqs

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/11/11 11:52, Jan Beulich wrote:
>>>> On 16.11.11 at 04:40, Shu Wu <superwushu@xxxxxxxxx> wrote:
>> In the changes I noticed the extra_dom0_irqs, which should be 0 by default
>> in r20142, was set to 256 in r20143, and caused default number of Dom0's
>> nr_pirq to exceed 256. Maybe this prevent IRQ of HP RAID controller, I
>> don't quite know about, though. After I set it to 32 (the same number as
>> extra_guest_irqs) the cciss.ko worked well. Although I could set this value
>> by "extra_guest_irqs=32,32" in boot param, there are still problem:
> That would hint at the IRQ number (presumably an MSI one) getting
> stored in too narrow a field somewhere in the kernel.

Is your kernel being built with per-cpu IDTs, or is it with one shared IDT?

~Andrew

>> 1. The argument for dom0 extra irqs, the one after the comma, is
>> undocumented.
> Feel free to submit a patch to update the respective documentation.
> But for your purpose you don't even need the second value afaiu.
>
>> 2. What is the reason of the magic number 256 for Dom0, and 32 for DomU in
>> Xen 4.x by default?
> They're not magic in any way; if they're found to be too small for a
> significant portion of systems, they could get bumped (but not
> lowered).
>
>> nr_irqs_gsi is only 16 on x64 arch, but the total
> That you speak of one particular system. Most that I work with have
> larger values.
>
>> nr_pirq would be more than 256. The magic number still exists in the newest
>> code. This is bad hardcode and may cause very elusive fault for newbie
>> user, maybe you can have a better solution.
> The problem is that we can't judge reasonable for everyone values
> here. As long as they serve a majority, we're fine with requiring the
> few remaining systems to be run with a command line override.
>
> Speaking of which, one option possible after work that happened over
> the last couple of months would be to get rid of ->nr_pirqs altogether,
> using nr_irqs again instead. That would make things only worse for your
> case though, as you wouldn't then have a way to override the system
> determined values.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel