search for: inval_back

...pages to a resource. > + > + This assign an array of guest pages (struct virtgpu_mem_entry) as "assigns" > + 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 T...

...pages to a resource. > + > + This assign an array of guest pages (struct virtgpu_mem_entry) as "assigns" > + 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 T...

...value of resources, since we've no idea if the host driver will store them in VRAM or main memory. Quite how to fail gracefully is a question, 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...

...value of resources, since we've no idea if the host driver will store them in VRAM or main memory. Quite how to fail gracefully is a question, 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...

...en every > VIRTGPU_CMD_RESOURCE_FLUSH or is does the assignment persist? Assignment is persistent. > > + 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. No particular reason I think. Dave? cheers, Gerd

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