[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] default value of extra_dom0_irqs
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |