|
|
|
|
|
|
|
|
|
|
xen-users
Re: [Xen-users] [XEN 3.3 - PCI passthrough] - interaction latencies with
Thanks for your help Ken,
I'm gonna have a look to the USB over IP solution. Nevertheless, in addition to my post, I ran further tests and noticed that when processing test on dom0 (no passthrough), everything works fine (no more latencies).
So, I'm about to conclude that the problem is due to PCI passthrough. I'm a litlle bit surprised, cause I thought that doing this would have given direct USB access.
Is it known that pci passthrough pull down performances?
Furthertmore, I've read that XEN 3.4 will introduce virtualized USB driver. So can we concluide that no more support will be done on PCI passthrough?
Finally, do you have any perf issues running USB over IP?
Tks a lot!
Jérémie
2009/1/9 Ken Cobler <kcobler@xxxxxxxxxxxxxx>
jer jer wrote:
Hi everybody!
I'm a pretty new XEN user (3.3) and I need your help on a weird situation.
In fact I cannot conclude if it could be a XEN problem or not. So I hope you will be able to guide me.
You will find below what my project is and as you guess ...the problem!
OBJECTIVE :
===========
- validate XEN solution for potential projects
- setup a paravirtualized environment
- embedd on a domU, software interacting with a USB connected desktop RFID reader
ENVIRONMENT :
=============
- XEN 3.3
- paravirtualized environment
- dom0 : linux 2.6.24-19-xen (ubuntu) installed with no graphical interface
- domU : linux 2.6.24-19-xen (ubuntu) installed with gnome and vncserver
- PCI passthrough to dedicate all USB controllers to the single domU
- domU is installed in a file-backed VBDs
BASIC RESULT:
=============
- dom0 and domU boots well
- PCI passthrough works
- system is stable
- on domU, lsusb shows the device connected
USB DEVICE :
============
- RFID desktop reader (STID)
- serial communication ("/dev/ttyUSB0) 9600 8 n 2
- very short instructions sent and received asynchronously (5 bytes) ; minimum system stress...
EMBEDDED SOFTWARE :
===================
- very basic test software that polls the device for an event
- if event detected, send a sound instruction to the device
- communication with the device is done via the serial dev file "/dev/ttyUSB0"
- tested on non virtualized environment : no latency on execution and test succeeds
PROBLEM :
=========
- running the soft from the console (xm console) without GUI introduces hudge execution latencies
- if we connect our appliance from a remote PC via vncviewer, gnome is displayed and run the same soft from an Xterm makes the execution much more faster
and coud almost be compared to non-virtualized environment perfs.
- Note that I've tried to connect via SSH without and then with X exporting, and latencies are still noticed
- it seems that latencies are only seen when interacting with the device
- Finally, we do not want to embedd any window manager such as gnome/KDE for footprints concerns
- soft have been written in C and JAVA but results are the same
HELPPPPP:
=========
As you see, it is a very strange problem and I can't find out who's responsible for that :
- is it a XEN problem?
- is it a console problem?
- is it a PCI passthrough problem?
- does gnome/vnc introduces implicits optimizations?
Furthermore, in order to find some clues:
- can you confirm me that XEN 3.3 does not support USB2.0 (not really needed here ...)
- I often have a system crash connecting USB mass storage devices (even dom0 get frozen) ; is it a known bug? I haven't found anything on forums.
- based on what I've read (and test) I cannot use newer XEN kernels if I want to keep PCI passthrough working
- are there some "best practices" to optimize USB passthrough
I've process a lot of diff, compare, readings and I have to tell you I've no more idea to solve this silly problem. Any help is thus welcomed!!
Thanks a lot for your help!
Cordially,
Jérémie
I've had difficulty with USB and Xen (using Windows HVM guests). I've tried the PCI approach as well.
Xen uses QEMU to run HVM guests. QEMU can only allow accept one USB device to the HVM guest. I was unable to successfully allocate a complete USB host controller to the domU (that was recognized by domU).
PCI approach requires that dom0 cannot grab a PCI card and leave it for the domU (which is handled through boot kernel parameters). I was never successful in getting that to work from the domU side. I could get dom0 to release the PCI device, but could not get domU to recognize the device.
My latest approach that I am working on is using USB over IP devices. Since both dom0 and domU have a network interface, I could attach the USB device to dom0 and let domU get it through the USB over IP. There are a couple of implementations for Windows and some for Linux, but, very limited on ability to do both (which is what I need for my application).
In your case, since both dom0 and domU are Linux, you might consider this solution from IncentivePros
http://www.incentivespro.com/downloads.html#usb-server
The USB server + USB Client Beta (at the bottom of the page) is an open source Linux to Linux USB over IP solution.
Ken Cobler
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|