From: Avi Kivity <avi@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Erik Brakkee <erik@brakkee.org>, Jan Kiszka <jan.kiszka@web.de>,
kvm@vger.kernel.org
Subject: Re: USB Passthrough 1.1 performance problem...
Date: Tue, 14 Dec 2010 12:02:03 +0200 [thread overview]
Message-ID: <4D07409B.2080602@redhat.com> (raw)
In-Reply-To: <CC762BE0-21C1-4E98-B012-67729669054C@suse.de>
On 12/13/2010 10:25 AM, Alexander Graf wrote:
> >>
> > Is your point in this case that USB in a VM based on PCI passthrough will always have problems when it comes to more real-time issues or does this only apply to USB passthrough? I can imagine that PCI passthrough is better since it uses hardware support. By the way, I have seen issues in the past whereby the tv card stopped working because of high load on the server running natively so real-time issues also exist apart from virtualization.
>
> IIRC the reason that PCI passthrough with EHCI performs as badly as it does is that BARs< 4k get passed through using the slow path (trap to qemu, issue MMIO in user space). Unfortunately, EHCI seems to have a 256 byte BAR region usually that is used for some handshaking:
>
> 00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
> Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> Latency: 64, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 17
> Region 0: Memory at c8014400 (32-bit, non-prefetchable) [size=256]
>
That could certainly be optimized. If the BAR is all along in its page,
both on guest and host (if not, we can migrate it, at least on the
host), we can use the same offset within the page on the host as it
appears on the guest, and assign the entire page.
We should make sure SeaBIOS uses a minimum alignment of 4k for mmio BARs.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-12-14 10:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-12 11:47 USB Passthrough 1.1 performance problem Erik Brakkee
2010-12-12 20:59 ` Erik Brakkee
2010-12-12 22:16 ` Jan Kiszka
2010-12-12 22:31 ` Erik Brakkee
2010-12-13 8:25 ` Alexander Graf
2010-12-14 10:02 ` Avi Kivity [this message]
2010-12-14 10:11 ` Alexander Graf
2010-12-31 17:00 ` Kevin O'Connor
2010-12-13 23:27 ` Jan Kiszka
2010-12-13 23:50 ` Kenni Lund
[not found] ` <3047113345.976756218@brakkee.org>
2010-12-14 0:47 ` Kenni Lund
[not found] ` <5085473063.976781602@brakkee.org>
2010-12-14 11:55 ` Kenni Lund
2010-12-14 12:05 ` Daniel P. Berrange
2010-12-14 21:47 ` Erik Brakkee
2010-12-14 23:44 ` Kenni Lund
2010-12-16 16:23 ` Erik Brakkee
2010-12-16 21:46 ` Erik Brakkee
2010-12-24 18:19 ` Erik Brakkee
2010-12-13 10:36 ` Gerd Hoffmann
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=4D07409B.2080602@redhat.com \
--to=avi@redhat.com \
--cc=agraf@suse.de \
--cc=erik@brakkee.org \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox