Is driver mode available for an interface on a VM? On Virtualbox I could only load my XDP program in generic mode. Is this the case in general for all VMs? Since XDP driver mode support depends on whether the driver supports it, I'm wondering if it's possible for an interface on a VM to support driver mode. If so, are there any VM interfaces that support XDP driver mode?
Yes, XDP support for virt_io(paravirtualized network adapters) has been supported since kernel v4.10. I believe virtual box will default to emulation of actual hardware instead of using virt_io, so you might need to do some tweaking in your VM settings to get everything to work.
Sources/further reading:
https://github.com/torvalds/linux/commit/f600b690501550b94e83e07295d9c8b9c4c39f4e
https://patchwork.kernel.org/project/kvm/cover/20191126100744.5083-1-prashantbhole.linux#gmail.com/ (Different update, disregard for this question)
https://lwn.net/Articles/708380/
Related
In ESXi console I can see my device with lsusb list
And in vm settings I add new USB Device and select my usb from dropdown list, and save settings.
But after that, I could neither see my device in windows server nor in vm configuration!
And when I try to add new device it doesn't show up in dropdown list anymore.
But still can see my device in lsusb list.
This is because the device in question is a USB storage device, specifically a flash drive. A quick Google has this hit: "S102 Pro Advanced USB 3.2 Flash Drive | Buy Now". AFAIK there is no workaround. Gory details follow in the next paragraph. Peruse at your own risk.
In vSphere ESXi 6.5 and earlier releases of ESXi the USB driver stack was a "vmklinux" driver stack with individual drivers for each device type, including USB host controllers. Thus if your installation was on a SCSI disk or PXE booted over the network you didn't need the USB storage driver at all and you could unload it and then pass the device through to a VM. Unloading the driver wasn't offically supported but could be done at the esxcli command line or if you wanted to be really daring you could delete it from your bootbank image. Note that "deleting" was only theoretical as you would really be replacing the driver module with a file of size 0 in the last loaded tar image (the only one that is customer configurable) and could thus be undone, but I digress.
The new USB native driver stack that debuted in vSphere ESXi 6.7 is a monolithic driver which means that it is not possible to unload only the storage driver. You could unload or clobber the entire USB stack but then you'd lose the keyboard and perhaps other things plus the ability to pass any USB device through to a VM. The disadvantages of monolithic USB drivers are well known and are the reason that Linus himself got involved in the redesign of the long gone Linux monolithic USB driver from over a decade ago, but I again digress. As to why VMware "improved" things by replacing a USB stack with half a dozen or more USB drivers with a monolithic stack with all the attendant disadvantages, you'd have to ask them. Feel free to request that they break the driver up into constituent modules as they know how to do this.
What is the additional advantage of developing a full UMDF windows driver if a CDC device is detected as a virtual COM port?.
I have some experience with embedded examples using a microcontroller, both communicating with a terminal like teraterm or using a dedicated USB peripheral that allows for cdc or hid functionality.
Are these drivers the ones you download and install before using any USB device? It is not clear yet what features are avaialble through the host driver.
Often on Windows the "driver" for a USB serial device is no more than an inf file that maps the device VID/PID to the Microsoft usbser.sys CDC/ACM driver.
Recent releases of Windows 10 appear to have stopped insisting that each CDC/ACM have a VID/PID specific inf file, and will load the standard driver for any device that presents as a CDC/ACM device.
The advantage of having a VID/PID specific inf file is that your device can have a vendor specific "friendly name" which can be used in applications to more easily identify your device, rather than just appearing as a generic "USB Serial Device".
One problem with Microsoft's usbser.sys driver (and Linux and Mac OS are no different) until recently was that if you disconnect the USB device, the driver is unloaded even if an application has the COM port open, and the application must close and reopen the port to recover when reconnected. I have previously used a custom driver (provided by a third party), that does not unload if an application has the port open, so that when the USB cable is reconnected, the data connection continues as normal, just as it would if it were an RS-232 cable. However, again in recent versions of Windows 10 I have noticed that usbser.sys appears to exhibit this behaviour in any case.
Note that when you do provide your own driver file, or even just a custom inf file, you will be required to go through WHQL testing in order for your device to be allowed on Windows 10, or to load without warnings on earlier versions. To do that you will need a USB.org assigned VID, an Extended Validation code-signing certificate, and either the tools and facilities to perform the testing, or pay a test house to perform the testing. That all gets somewhat expensive, and may be prohibitive for low volume, low value or non commercial products.
At one time Microsoft too charged for WHQL processing submissions, but no longer do so. That is however little combination since at the same time they changed to requiring an EV certificate and stopped a deal the used to have for low-cost certificate.
The advantage of WHQL qualification is your driver will be provided by Windows Update.
If you are using a USB serial bridge chip rather than your own USB stack and USB controller, then there is a lower cost solution. These chips can be customised with your own VID/PID and descriptors, and the vendor's existing WHQL can be associated to your device so you get all the advantages of your own driver without the costs. Most vendors will even allow you to use their VID and will assign you a unique PID so you can avoid USB.org fees. I have used this route with both Prolific and FTDI devices; it is by far the most cost effective solution.
I work in developing and creating virtual printers, with QEMU as the hypervisor (no KVM-only Qemu). Can libvirt library be used to manage virtual printers? Currently, I am investigating on how to convert the qemu command line parameters into dom.xml and try bringing up the virtual printer using virsh. I see that libvirt adds it's own parameters apart from the one provided (like for example vga), which are more suitable for a PC and not necessary for virtual devices like a printer.
Has livirt been successfully used to virtualize other devices or is it specifically aimed only for a PC environment?
Libvirt will only automatically add an <video> element for VGA, if you have asked for a <graphics> element. So you can just leave out the latter to avoid this extra VGA device being added. What you're trying todo is pretty uncommon, so there may be other edge cases you hit like this.
We are developing an embedded system which will use a PC motherboard running Linux or Windows Embedded (have not decided which one). The board will read data from FPGA via PCI Express.
Novice question: do we have to develop our own PCIe driver or we can use something from the operating system? If we need our own, can you recommend a resource?
It really depends on what kind of data you want to transfer with the device. If you just want register read/write you could just mmap /dev/mem and have a user space driver.
If you need to do DMA or interrupt then you'd likely have to write your custom driver.
Yes, unless your device corresponds to a standard device profile, you will need a custom device driver. Because you have not selected your operating system yet, your question about resources is pretty wide open still since obviously the OS selection directly affects driver design. For Windows you probably want to start here. Under Linux, perhaps here.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.