On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote: > Hi Dmitry, > > On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp <dmitry.sepp@xxxxxxxxxxxxxxx> wrote: > > > > Hi Keiichi, > > > > Thanks for the clarification. I believe we should explicitly describe this in > > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a problem > > there. If it is a guest allocated resource, we cannot consider it to be free > > until the device really releases it. And it won't happen until we issue the > > next ATTACH call. Also, as we discussed before, it might be not possible to > > free individual buffers, but the whole queue only. > > In the case of the encoder, a V4L2 driver is not supposed to let > user-space dequeue an input frame while it is used as reference for > the encoding process. So if we add a similar rule in the virtio-video > specification, I suppose this would solve the problem? > > For the decoder case, we have a bigger problem though. Since DMABUFs > can be arbitrarily attached to any V4L2 buffer ID, we may end up > re-queueing the DMABUF of a decoded frame that is still used as > reference under a different V4L2 buffer ID. In this case I don't think > the driver has a way to know that the memory resource should not be > overwritten, and it will thus happily use it as a decode target. The > easiest fix is probably to update the V4L2 stateful specification to > require that reused DMABUFs must always be assigned to the same V4L2 > buffer ID, and must be kept alive as long as decoding is in progress, > or until a resolution change event is received. We can then apply a > similar rule to the virtio device. Sounds like a generic kind of problem - how do other devices solve it? _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel