I need some documents about it (must be detailed) and,is KVM support it????
If yes, how to enable it and use it?
My goal is to virtualize intel usb controller(onboard 0000:00:14.0) and distribute it to 2 guests.
Passthrough can only be used by 1 guest.
xHCI-IOV is an xHCI-specific extension to SR-IOV (Single Root I/O Virtualization), the PCI specification that lets a single PCI device expose multiple functions.
Of the functions, one is a physical function and the others are virtual functions. Virtual functions have some limitations regarding the features they can support, but the spec says that no function cannot interfere with the functioning of the others.
However, I don't think Linux supports it. The XHCI_EXT_CAPS_VIRT symbol only appears in debug code, and there should probably be a separate driver for virtual xHCI functions as well.
Related
I read only grid 1.0 and 2.0 products can virtualize.
I read this product share cuda and dedicate framebuffer.
Is it not possible generic nvidia card virtualize like grid product only using software method(iommu, vfio-pci, ovmf, mmu ...) ?
Or any project exist?
It looks like marketing stuff. You need to pay a LOT of money to use "professional" adapters like GRID. AFAIK, you even need to pay for virtual video drivers that will be installed on your virtual machine. So you can't do virtualization with generic videocard just because nvidia needs a little bit more of money.
Unfortunately no projects exists that allows us to use consumer videocard in virtualization. The only thing you can do with generic card is to passthroug it completely to one of virtual machines.
I try to understand how they both relate to each other. As far as I know, they both can be a part of the HAL. In case of a communication between an application and a graphics card - can an API get the job done on its own or do we have to rely on them both? Can an API directly communicate with the hardware or do we always need a driver in-between, which translates the command of the API?
TL;DR
Think of an API as a specification that describes what to do, while a driver is an implementation that describes how to do it.
Details
As a contrived example, imagine we have three different audio cards that we want to play nicely with multiple operating systems. We can define an API for the card manufacturers that says, "Each card must support four methods: mute(), playsound(sound), volumeup() and volumedown()". By defining the API, we get a common interface that allows the operating system designers to support the audio devices without worrying about the hardware details. They know that if they want to mute the sound card, they can call mute(), or if they want to turn the volume up, they call volumeup().
It is then up to the device manufacturers to implement a driver that actually performs those actions. The driver will vary between the three different audio cards because they are different at the hardware level, but the API is consistent so the next higher abstraction level (the OS) doesn't need to know how to deal with the hardware.
For a more concrete example, consider the Advanced Control & Power Interface (ACPI) specification. It defines a common interface for operating systems to manage power consumption and thermal characteristics of hardware devices. There are methods that a device driver or firmware must implement in order to be "ACPI Compliant". This allows Windows operating systems and Linux variants to both perform the same actions on hardware devices without needing to implement their own drivers for the hardware
Note: Windows performs ACPI actions through acpi.sys, which they call an "ACPI Driver". Don't let the terminology confuse you; even though they call it a driver, it is really a window into the ACPI interface. Linux uses the acpi kernel module to do the same thing, and Linux doesn't call it a driver. Perhaps ACPI wasn't the best example, but I don't have anything better at the moment.
I'm wondering if there's any "mainstream" wireless chipsets/adapters for PC's that have open specifications, to a level that would permit one to implement a custom driver (i.e. specifications of registers, mode of operation etc.)? It's OK if the chipset requires the upload of binary blobs (for which the source isn't available) to the chip/card itself etc. as long as the host <-> adapter interface is public. I'm looking for it mainly out of interest to see what this interface looks like, but I might also be interested in doing some coding myself. Thanks!
You have OpenWRT which is a fully capable open source router operation system, TP-LINK products are based on OpenWRT.
You may be also interested in https://www.zigbee.org/ more oriented to the Internet of Things and M2M wireless sensor networks.
You probably want to check the Atheros WiFi chipset and its open source drivers, for examples ath5k and ath9k. These drivers are preinstalled in Linux kernel. It's widely used in academy, at least, and adopted by many off-the-shelf NIC.
I'm writing a virtual machine - not an existing architecture emulator like Virtualbox, but rather something like the JVM or BEAM - with its own instruction set, memory model, etc. Eventually I'm planning to implement a very small and simple (but turing-complete) high-level language that would compile into its bytecode, just for fun.
Of course, the machine must have some support of I/O, but I do not want to limit it only to manipulations with stdin/stdout. I imagine something like modular "virtual devices", which can be implemented as shared libraries so that the VM can load them at runtime and communicate with them through a standard interface. This way, for example, we can have "virtual devices" for standard input/output, graphics (imagine a virtual device that lets your VM program draw stuff inside an SDL window) or maybe even network.
The question is: how should the programs written for the VM communicate with the virtual devices? I decided to mimic techniques which are employed with actual hardware and learned about port-based I/O and memory-mapped I/O. However, I'm not sure which one of them is more suitable for my goals. Can you suggest which one is better or maybe even point out a totally different technique for dealing with input/output?
Thanks in advance.
Both memory-mapped and port based are inappropriate for most I/O.
DMA request with block-copy is usually what you want.
I have a piece of hardware that sends USB data over ethernet (only the data stored in the package will be send). On a remote PC the data is recieved via ethernet. How can I send this data to the USB driver so it translates the data into commands applications can use?
You're better off getting hardware that does the reciprocal, sends the IP-based USB information to the USB subsystem, rather than try and hack the software driver itself. I can't imagine your hardware vendor doesn't have a device that does this.
You need a server listening on whatever port/socket that you are trying to connect to. Twisted Matrix makes decent Python libraries for network communications.
I think this is going to be troublesome.
USB is generally set up to associate a driver with a connected device, based on the device's various ID numbers, as discovered during bus traversal.
Your data comes in over Ethernet, so the platform's USB driver stack won't know anything about the device in question. This means you somehow need to directly talk to the proper driver, and also get it prepared to handle events from a (from its point of view) non-connected device.
I can think of several reasons why even a well-designed USB stack won't handle this happily.
On Linux, you might be able to "cheat" by interpreting the data yourself and sending it on, using the same API:s the actual driver would have used. That won't work for any USB device of course, it requires you know what the device is.
It's doable on windows as well, but you need a lot of kernel/usb knowledge to make it work i don't think i will be wrong by estimating this task as few man years (you can reduce this estimation dramatically if you have a limited selection of devices/types of device to support.
You will need to develop a bus driver that will simulate the host controller driver to the native usb host, unfortunately this interface is not public and we did not managed to get MS cooperation on that.
There is additional option to work on hub level, instead on controller level, this interface is available, but i did not managed to find my notes on that.
You can download the evaluation version and investigate the driver stack it might give you a clue where to start.