From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: default value of extra_dom0_irqs Date: Wed, 16 Nov 2011 13:00:32 +0000 Message-ID: <4EC3B3F0.9090608@citrix.com> References: <4EC3B2270200007800061469@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EC3B2270200007800061469@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 16/11/11 11:52, Jan Beulich wrote: >>>> On 16.11.11 at 04:40, Shu Wu 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@lists.xensource.com > http://lists.xensource.com/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com