But you want Aero too in VMs, don't you
Announcement
Collapse
No announcement yet.
OpenCL, OpenGL 3.1 State Trackers "Hopefully Soon"
Collapse
X
-
-
Originally posted by remm View PostBeyond that, I don't know either the reason for the acquisition. Maybe it is for 3D virtualization but that seems odd to me (besides running Windows games, I don't see the benefit, so making real money from that seems difficult).
Comment
-
If you wanted a single, standard API to run across a client/host boundary Gallium3D seems like a pretty good choice.
Also if you want to pick up a team familiar with 3D on Linux there's probably nobody better in the world.
Just a thought.Test signature
Comment
-
Originally posted by bridgman View PostIf you wanted a single, standard API to run across a client/host boundary Gallium3D seems like a pretty good choice.
Also if you want to pick up a team familiar with 3D on Linux there's probably nobody better in the world.
Just a thought.
That sounds very dangerous from a security point of view. Wouldn't it be possible to have the GPU write to memory outside of the client address space?
But very interesting, if that is indeed what they are doing
Comment
-
Originally posted by bridgman View PostDefinitely would have to go through the hypervisor and have contents checked; the question is just *what* goes through the hypervisor.
Should there then be a Gallium3D driver on the host, that then would act like a hypervisor for 2D/3D calls?
There exist network cards that are aware that there is running virtual guests on the host, so the network card can't be used to do code injection by DMA.
If they exposed the GPU, I would think that it would be possible to have shaders to write anywhere in memory.
...Unless they encrypted and hashed the memory and page tables
Originally posted by bridgman View PostThis is all just idle speculation, I'm not in on the secret plan or anything.
Let's just hope, that they don't finish the new Gallium3D API, before we have stable 3D drivers
Comment
-
Originally posted by Louise View PostThis is pretty complicated stuff
Should there then be a Gallium3D driver on the host, that then would act like a hypervisor for 2D/3D calls?
There exist network cards that are aware that there is running virtual guests on the host, so the network card can't be used to do code injection by DMA.
If they exposed the GPU, I would think that it would be possible to have shaders to write anywhere in memory.
The current DRM already checks register accesses and buffer locations before allowing a command packet to get through to the hardware. As the stack transitions to using a common memory manager and passing handles rather than pointers the checking should get easier.
The buffer checking code is mostly here (for 6xx/7xx anyways) : http://cgit.freedesktop.org/~agd5f/d...h=r6xx-r7xx-3dLast edited by bridgman; 17 May 2009, 02:32 PM.Test signature
Comment
-
Originally posted by bridgman View PostThe problem with 3D is that (a) client programs use it a lot, and (b) it's one of the places where letting the client program get to the hardware is almost totally impractical from a performance POV. That kind of implies drivers which are aware that they are running on a virtualized system.
Maybe they have found away to talk to each core, so e.g. one guest gets 50 of the GPU cores?
Originally posted by bridgman View PostThe current DRM already checks register accesses and buffer locations before allowing a command packet to get through to the hardware. As the stack transitions to using a common memory manager and passing handles rather than pointers the checking should get easier.
I wonder how Red Hat feels about all this. They bought Qumranet last year, which are best known for KVM.
But Red hat also got Solid ICE, which virtualizes Linux and Windows desktops.
Maybe VMware are afraid of what Red Hat will be able to deliver???
Comment
Comment