search for: detach_back

...gns" > + the backing store for a resource. These pages are then used for the > + transfer operations for that resource from that point on. > + > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: > + Command: struct virtgpu_resource_inval_backing Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is logical since there is also an "attach" command. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.linuxfoundation.org/piper...

...gns" > + the backing store for a resource. These pages are then used for the > + transfer operations for that resource from that point on. > + > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: > + Command: struct virtgpu_resource_inval_backing Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is logical since there is also an "attach" command. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.linuxfoundation.org/piper...

...uestion, probably need to report to the guest what context did the allocation and see if we can destroy it. >> > + >> > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: >> > + Command: struct virtgpu_resource_inval_backing >> >> Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is >> logical since there is also an "attach" command. > > No particular reason I think. Dave? > Not reason I can remember, I think I was thinking of having separate inval and detach at one point, but it didn't really make any sense, so renamin...

...uestion, probably need to report to the guest what context did the allocation and see if we can destroy it. >> > + >> > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: >> > + Command: struct virtgpu_resource_inval_backing >> >> Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is >> logical since there is also an "attach" command. > > No particular reason I think. Dave? > Not reason I can remember, I think I was thinking of having separate inval and detach at one point, but it didn't really make any sense, so renamin...

...store for a resource. These pages are then used for the > > + transfer operations for that resource from that point on. > > + > > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: > > + Command: struct virtgpu_resource_inval_backing > > Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is > logical since there is also an "attach" command. No particular reason I think. Dave? cheers, Gerd

Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h...

Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h...

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a