This is not likely to happen at all in the foreseeable future.

We would need to do a lot more work than just making the PCI slot available to the VM.

I agree that this falls under the "it would be nice to have" umbrella. Given the technical challenges behind this, however, you're probably not going to see this feature included in our products.

-Daryll

Keep in mind one of the reasons we all love ESX. The lightweight VMkernel that allows for minimal virtualization overhead. By creating a driver in such a fashion, there would need to be quite a bit of modification and bloating of the vmkernel (to provide DMA, IRQs, and manage the memory assosciated with these functions). Perhaps with Intel's announcment of the Vanderpool project (http://www.tomshardware.com/hardnews/20040907_141505.html) some of the functionality of the VMkernel can be offladed, allowing for increased functionality in the vmkernel. **Content voluntarily deleted**

Scott

Message was edited by: sherold

You make a valid point, and I may be the one talking nonsense here, but VMware doesn't actually virtualize (in the sense of the word) the physical PCI devices it can currently use (NIC, SCSI, HBA) directly to the VMs. The guest operating system never sees these physical devices. They see emulated (for lack of a better word) devices at the vmkernel level. The vmkernel then transforms the proper requests back to the physical hardware. I have NO IDEA how they do this...I chalk it up to magic. I would think it would take significantly more code to supply direct interaction of virtual machines to the physical hardware by requiring that they include some form of direct physical hardware abstraction layer.

Scott

It is not that simple. I think that I already answered it in some other thread, but I'm lazy to look for it, so I'll retype it here.

There are three (or maybe more) problems with generic support for PCI cards:

(1) It is not easy to say whether host OS uses card or not. ESX makes it simpler, but we do not want to run ESX, yes?

(2) PCI cards can do busmastering. When you program hardware, you cannot distinguish programming of busmastering transfers from normal programming of card. So either you'll maintain 1:1 mapping between physical guest memory and host's physical memory (which means that you can run only one guest OS, and you'll have to use special host OS. So for hosted products busmastering is impossible, for ESX maybe, but with very huge costs.

(3) After we eliminated busmastering, there are interrupts. As only guest OS has an idea how to acknowledge (and deassert) interrupts generated by hardware, it means that we cannot share generic PCI's interrupt line with any other device which is used by host - as we only know how to disable IRQ on PIC/APIC/IOAPIC. Maybe PCI-X's generic IRQ enable on card can lift this requirement, but I'm afraid that touching this bit could change hardware behavior.

(4) After we eliminated cards with busmastering and interrupts - who's still in contest? I'm afraid that nobody. And from those devices which are still in contest we have to eliminate devices which can lockup PCI bus while programmed - for example (from my exprience) when you setup Matrox cards, there are time windows during which framebuffer access locks up card hard (not that all except old MillenniumI were eliminated by no-busmastering condition above, but you could try to run them without busmastering). So you do not want to run untrusted VMs, as VM can now crash your host.

Due to conditions above I do not think that generic PCI cards access is possible without BIG support from hardware. Maybe chipsets with IOMMU could shield PCI card's busmastering from damaging your system, but until IOMMU is generally available I'm afraid that there is no chance that anybody can implement usable framework.

If we talk about it, I think that instead of direct PCI access you should ask for API which would allow you to write your own virtual devices - that way, with device datasheet, you should be able to write simple pass-through filter which will know which accesses are for busmastering/interrupts and which are not, and then you can map/translate what needs to be translated, and pass through safe operations.