[PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug

[Zack Rusin]

On Wed, 2021-10-13 at 14:50 +0200, Daniel Vetter wrote:
> On Tue, Oct 12, 2021 at 05:34:50PM +0000, Zack Rusin wrote:
> 
> > On the flip side that does mean that vmwgfx and i915 need to redo
> > some
> > code. For vmwgfx it's probably a net positive anyway as we've been
> > using TTM for, what is really nowadays, an integrated GPU so maybe
> > it's
> > time for us to think about transition to gem.
> 
> Aside, but we're looking at adopting ttm for integrated gpu too. The
> execbuf utils and dynamic memory management helpers for pure gem just
> aren't quite there yet, and improving ttm a bit in this area looks
> reasonable (like adding a unified memory aware shrinker like we have
> in
> i915-gem).
> 

That would certainly be a big help. The situation that I want to avoid
is having vmwgfx using TTM for what no other driver is using it for.


> Also I thought vmwgfx is using ttm to also manage some id spaces,
> you'd
> have to hand-roll that.

Yes, it's work either way, it's likely less code with GEM but we'd lose
support for 3D on older hardware where our device did have dedicated
VRAM. 

Nowadays memory management in our device is rather trivial: every GPU
object is just kernel virtual memory. To allow our virtual device to
write into that memory we send it an identifier to be able to name the
object (we use id's but it could be just the kernel virtual address as
integer) plus a page table because, of course, vmx can't read guest
kernel's page tables so we need to map the kernel virtual address space
to physical addresses so that the host can write into them. So mm in
vmwgfx shouldn't require performance enhancing drugs to understand and
drug usage while writing vmwgfx code should remain purely recreational
;)

z