Re: [RFC PATCH 0/8] *** Refactor struct virtgpu_object ***

From: Gerd Hoffmann <kraxel@redhat.com>
To: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>,
	John Bates <jbates@chromium.org>
Subject: Re: [RFC PATCH 0/8] *** Refactor struct virtgpu_object ***
Date: Fri, 28 Feb 2020 11:28:10 +0100	[thread overview]
Message-ID: <20200228102810.wdrkt43oova7zib3@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAAfnVB=hPaGUtq=w9X5DGnsCAAjMzP_dTNKQm-4hG5ORD=2r+A@mail.gmail.com>

  Hi,

> > struct virtgpu_object {
> 
> Yeah, using "virtgpu_" rather than "virtio_gpu" makes sense.

It wasn't my intention to suggest a rename.  It's just that the kernel
is a bit inconsistent here and I picked the wrong name here.  Most
places use virtio_gpu but some use virtgpu (file names, ioctl api).

> > struct virtgpu_object_hostmem {
> >         struct virtgpu_object base;
> >         {offset, range};
> >         (...)
> 
> I'm a kernel newbie, so it's not obvious to me why struct
> drm_gem_shmem_object would be a base class for struct
> virtgpu_object_hostmem?

I think it is easier to just continue using virtio_gpu_object in most
places and cast to virtio_gpu_object_{shmem,hostmem} only if needed.
Makes it easier to deal with common fields like hw_res_handle.

In the hostmem case we would simply not use the drm_gem_shmem_object
fields except for drm_gem_shmem_object.base (which is drm_gem_object).

> Side question: is drm_gem_object_funcs.vmap(..) /
> drm_gem_object_funcs.vunmap(..) even possible for hostmem?

Sure.  Using ioremap should work, after asking the host to map the
object at some location in the pci bar.

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel