From mboxrd@z Thu Jan 1 00:00:00 1970 From: Justin Acker Subject: Re: xhci_hcd intterrupt affinity in Dom0/DomU limited to single interrupt Date: Thu, 03 Sep 2015 12:52:05 -0400 Message-ID: <1441299125.30502.12.camel@localhost> References: <55E839E3020000780009F3CD@prv-mh.provo.novell.com> <1292756745.962760.1441281893582.JavaMail.yahoo@mail.yahoo.com> <55E87DA6020000780009F59D@prv-mh.provo.novell.com> Reply-To: ackerj67@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZXXkA-0004V6-4r for xen-devel@lists.xenproject.org; Thu, 03 Sep 2015 16:52:10 +0000 In-Reply-To: <55E87DA6020000780009F59D@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2015-09-03 at 09:04 -0600, Jan Beulich wrote: > >>> On 03.09.15 at 14:04, wrote: > >>>> On 02.09.15 at 19:17, wrote: > >> From: Jan Beulich > >> Sent: Wednesday, September 2, 2015 4:58 AM > >>>>> Justin Acker 09/02/15 1:14 AM >>> > >>> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset > > Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) > >>> Subsystem: Dell Device 053e > >>> Flags: bus master, medium devsel, latency 0, IRQ 78 > >>> Memory at f7f20000 (64-bit, non-prefetchable) [size=64K] > >>> Capabilities: [70] Power Management version 2 > >>> Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ > >> > >> This shows that the driver could use up to 8 MSI IRQs, but chose to use just > > > >> one. If > >> this is the same under Xen and the native kernel, the driver likely doesn't > >> know any > >> better. If under native more interrupts are being used, there might be an > >> issue with > >> Xen specific code in the kernel or hypervisor code. We'd need to see details > > > >> to be > >> able to tell. > >> > >> Please let me know what details I should provide. > > I'd like to emphasize what I said in my previous reply: Apologies. The Webmail client doesn't support in-line replies or I couldn't figure out how to turn these on. Hopefully this is better. > > > Please, first of all, get your reply style fixed. Just look at the above > > and tell me how a reader should figure which parts of the text were > > written by whom. > > > >[...] > > > > I am still confused as to whether any device, or in this case xhci_hcd, > > can use more than one cpu at any given time. My understanding based on > > David's response is that it cannot due to the event channel mapping. The > > device interrupt can be pinned to a specific cpu by specifying the > > affinity. I was hoping there was a way to allow the driver's interrupt to be > > scheduled to use more than 1 CPU at any given time. > > The problem is that you're mixing up two things: devices and > interrupts. Any individual interrupt can only be serviced by a single > CPU at a time, due to the way event channels get bound. Any > individual device can have more than one interrupt (MSI or MSI-X), > and then each of these interrupts can be serviced on different > CPUs. > > Jan > Thanks for clarifying. To the original question, with respect to my limited understanding of the event channels and interrupts, each interrupt can be serviced on a different CPU using irqbalance or setting the affinity manually, but the same interrupt cannot be serviced by more than 1 CPU at a time? If so, is there a way around the 1:1 binding when loading the Dom0 kernel - a flag or option to use the native interrupt scheduling for some set of or all 8 CPUs that the device can schedule interrupts on when not loading the Dom0? The xhci_hcd, as one example, seems to perform better when it is able to have interrupts serviced by multiple CPUs.