From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: xhci passthrough
Date: Thu, 28 Oct 2010 17:12:23 -0400 [thread overview]
Message-ID: <20101028211223.GA23216@dumpdata.com> (raw)
In-Reply-To: <2010169160.20101028000118@eikelenboom.it>
On Thu, Oct 28, 2010 at 12:01:18AM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
>
> Due to a 2.6.37-merge-window kernel now being able to boot under Xen i was able to test my xhci controller under dom0 which i previously couldn't.
>
> The results:
> A) 2.6.37-merge-window kernel baremetal: Videograbbing while doing 20 iterations of make -j6 of kernel works.
> B) Xen + 2.6.37-merge-window kernel as Dom0: Videograbbing while doing 20 iterations of make -j6 of kernel works.
Great!
> C) Xen + 2.6.32.24 pvops dom0 + 2.6.37-merge-window kernel DomU: Videograbbing while doing 20 iterations of make -j6 still freezes the machine without a trace after a short while.
Ok, so it points to the 2.6.32.24 doing something funky, which unfortunatly does not help that much
as the xen patches that are in the 2.6.37-merge-window for IRQ are about the same
as what 2.6.32.24 has. Thought the 2.6.37-merge-window got tons of bells and whistles in the
generic Linux kernel code part.
These interrupts were for the MSI-X for the XHCI controller or was it legacy interrupts?
>
> An other interesting thing is the interrupt rate i see in /proc/interrrupts for the xhci controller, i measured for 5 minutes each time.
> In situation:
> A) About 3200 Interrupts/second
> B) About 3200 Interrupts/second
> C) About 7800 Interrupts/second, what would be 7.8 interrupt per ms which seems to work as long as you don't stress the rest to the limit.
> Which probably causes some sort of deadlock (some where in the path from device, xen, dom0/pciback , domU/pcifront, xhci driver, application.) when not delivered on time or when it boldly goes on a code path where no one has gone before ..
>
> Compared with a measurement of interrupts by a USB2 controller:
> Around 155 Interrupts/second
>
> Probably a silly question without a right answer ... but what interrupt rate would you guess it should be able to take ?
> And is it logically that when passed through it causes around 2.5 times more interrupts ?
>
> Now testing on a Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
>
> --
>
> Sander
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-10-28 21:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 22:01 xhci passthrough Sander Eikelenboom
2010-10-28 21:12 ` Konrad Rzeszutek Wilk [this message]
2010-10-28 21:54 ` Sander Eikelenboom
2010-10-29 12:13 ` Stefano Stabellini
2010-10-29 14:27 ` Konrad Rzeszutek Wilk
2010-10-29 14:37 ` Sander Eikelenboom
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=20101028211223.GA23216@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Xen-devel@lists.xensource.com \
--cc=jeremy@goop.org \
--cc=linux@eikelenboom.it \
/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.