A Virtual Gallium3D Driver Coming For VMware

[drag]

That could be what Sun's doing with Vbox...adding paravirtualization support to allow hardware to be controlled by drivers on the guest in a virtualized manner without impacting the host or the guest negatively.

This should be quite interesting to see how all this evolves. Someday I'd be able to dump the physical Windows install and just keep "Bill in a box" for those times I want to run a Windows program without all the hassles and bugs of Wine. This would be definitely good for those games and graphics apps that makers can't or won't port to Linux.

KVM already supports this, as does Xen I believe. Probably Vmware also. I suppose Vbox and any other virtualization can support it.


It's very important for server applications since emulating the network cards and using virtual ethernet is a big bottleneck. If you have a 10Gbs ethernet connection there is no chance in hell that even the best virtualization support can keep up with it using emulation or even paravirtualized drivers.


http://www.mjmwired.net/kernel/Docum...ntel-IOMMU.txt

And it has AMD IOMMU support also, of course.

The trouble with all of this stuff is finding the right motherboard and all that.

[drag]

I've been wanting to do this for years, to run a multi-seat box (multiple users on one machine, each with their own kbd+mouse+vga). I was disappointed a couple years ago when I got a core2 to find out that even with HW virt support, giving the guest direct VGA access wasn't possible.

What current and future x86-64 hardware has an IOMMU suitable for guest video drivers? Anyone more up to date on this than I am?

Nobody.

Like I said it's more complicated then normal hardware. DMA isn't the issue. Video cards are special cases and you have to have support in the vbios themselves for this sort of thing.

[Peter_Cordes]

The ultimate future will just being able to hand off complete control of the video card to the guest OS. That is you let native drivers access the hardware in the native way, but be it controlled in a guest.

We already have that for most PCI devices on very new hardware. KVM and friends have the ability to hand off control of hardware to guests, but with video cards (of course) they are to complicated to be handled in such a ham-fisted manner.

What makes them "too complicated" is DMA. Vid cards directly access host memory, e.g. to fetch textures, using physical memory addresses programmed by the driver. The problem is that a graphics driver running in a guest will put vm guest "physical" addresses on the card, not real hardware physical.

Either you code a VM-aware version of the driver to work around this, and run an insecure VM that trusts the guest not to use the vid card to read memory outside the VM, or you need a hardware IOMMU. Some current hardware has IOMMUs, but I can't remember which. Except for server stuff, probably only AMD and maybe Nehalem, since it's a lot easier to implement when the PCIe <-> RAM path goes through the CPU anyway.

I've been wanting to do this for years, to run a multi-seat box (multiple users on one machine, each with their own kbd+mouse+vga). I was disappointed a couple years ago when I got a core2 to find out that even with HW virt support, giving the guest direct VGA access wasn't possible.

What current and future x86-64 hardware has an IOMMU suitable for guest video drivers? Anyone more up to date on this than I am?

[DeepDayze]

Yeah. something like that.

The best you'd be able to do is poke a hole in the VM through 'paravirtualization' technique and say "This memory is directly accessable by both the drivers in the host and in the guest". Then the state trackers issue commands that get read in by the rest of the gallium drivers on the host.

So your adding in a few context changes and that sort of thing. You'd probably get 60-70% performance for most operations.

The ultimate future will just being able to hand off complete control of the video card to the guest OS. That is you let native drivers access the hardware in the native way, but be it controlled in a guest.

We already have that for most PCI devices on very new hardware. KVM and friends have the ability to hand off control of hardware to guests, but with video cards (of course) they are to complicated to be handled in such a ham-fisted manner.

That could be what Sun's doing with Vbox...adding paravirtualization support to allow hardware to be controlled by drivers on the guest in a virtualized manner without impacting the host or the guest negatively.

This should be quite interesting to see how all this evolves. Someday I'd be able to dump the physical Windows install and just keep "Bill in a box" for those times I want to run a Windows program without all the hassles and bugs of Wine. This would be definitely good for those games and graphics apps that makers can't or won't port to Linux.

[drag]

At some point VM 3D acceleration could be mature enough for people to play many graphics intensive games on Windows running in a VM. Imagine loading up Windows XP/W7 in a VM and play a game such as CoD or Crysis at a darn good playable framerate as if you had booted Windows off bare metal?

Yeah. something like that.

The best you'd be able to do is poke a hole in the VM through 'paravirtualization' technique and say "This memory is directly accessable by both the drivers in the host and in the guest". Then the state trackers issue commands that get read in by the rest of the gallium drivers on the host.

So your adding in a few context changes and that sort of thing. You'd probably get 60-70% performance for most operations.

The ultimate future will just being able to hand off complete control of the video card to the guest OS. That is you let native drivers access the hardware in the native way, but be it controlled in a guest.

We already have that for most PCI devices on very new hardware. KVM and friends have the ability to hand off control of hardware to guests, but with video cards (of course) they are to complicated to be handled in such a ham-fisted manner.

[DeepDayze]

Then it won't be a problem because 99% of gamers are using Windows. Therefore, no Gallium3D-based cheats there

However, doesn't the anticheat software run in the same session as the game?

Well, you can just glean the necessary information from the VM and inject it into the scene on the host using that nifty Gallium3D interface.

haha I am sure you can create some cheats that run as a sort of "rootkit" that is undetectable by common anticheat software that runs either on the server or on the client.

Just the same, having decent 3D virtualization would be nifty for being able to run games that are problematical in Wine...just load up a Windows VM and run the game!

Then it won't be a problem because 99% of gamers are using Windows. Therefore, no Gallium3D-based cheats there

you never know if some enterprising game hacker can create cheats that can hook into Gallium3D that no anticheat program can detect

[RealNC]

Then it won't be a problem because 99% of gamers are using Windows. Therefore, no Gallium3D-based cheats there

[Remco]

How can the wallhack inject its code from outside the VM in a process running in the VM?

Well, you can just glean the necessary information from the VM and inject it into the scene on the host using that nifty Gallium3D interface.

[RealNC]

If everything becomes virtualized, that will be the end of anti-cheat software. How can you detect a wallhack that runs outside the VM?

How can the wallhack inject its code from outside the VM in a process running in the VM?

[Remco]

At some point VM 3D acceleration could be mature enough for people to play many graphics intensive games on Windows running in a VM. Imagine loading up Windows XP/W7 in a VM and play a game such as CoD or Crysis at a darn good playable framerate as if you had booted Windows off bare metal?

If everything becomes virtualized, that will be the end of anti-cheat software. How can you detect a wallhack that runs outside the VM?