On 5/10/24 19:12, Dmitry Osipenko wrote: > On 5/10/24 13:56, Akihiko Odaki wrote: >> On 2024/05/09 21:39, Dmitry Osipenko wrote: >>> On 5/5/24 09:37, Akihiko Odaki wrote: >>>> On 2024/05/02 4:02, Dmitry Osipenko wrote: >>>>> On 4/27/24 08:48, Akihiko Odaki wrote: >>>>>>> >>>>>>> The VIRTIO_GPU_FILL_CMD() macro returns void and this macro is >>>>>>> used by >>>>>>> every function processing commands. Changing process_cmd() to return >>>>>>> bool will require to change all those functions. Not worthwhile to >>>>>>> change it, IMO. > >>>>>>> The flag reflects the exact command status. The !finished + >>>>>>> !suspended >>>>>>> means that command is fenced, i.e. these flags don't have exactly >>>>>>> same >>>>>>> meaning. >>>>>> >>>>>> It is not necessary to change the signature of process_cmd(). You can >>>>>> just refer to !finished. No need to have the suspended flag. >>>>> >>>>> Not sure what you're meaning. The !finished says that cmd is fenced, >>>>> this fenced command is added to the polling list and the fence is >>>>> checked periodically by the fence_poll timer, meanwhile next virgl >>>>> commands are executed in the same time. >>>>> >>>>> This is completely different from the suspension where whole cmd >>>>> processing is blocked until command is resumed. >>>>> >>>> >>>> !finished means you have not sent a response with >>>> virtio_gpu_ctrl_response(). Currently such a situation only happens when >>>> a fence is requested and virtio_gpu_process_cmdq() exploits the fact, >>>> but we are adding a new case without a fence. >>>> >>>> So we need to add code to check if we are fencing or not in >>>> virtio_gpu_process_cmdq(). This can be achieved by evaluating the >>>> following expression as done in virtio_gpu_virgl_process_cmd(): >>>> cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_FENCE >>> >>> This works, but then I'll add back the res->async_unmap_in_progress >>> because we need to know whether unmapping has been started. >>> >> >> Isn't the command processing paused when an unmapping operation is in >> progress? > > The virtio_gpu_process_cmdq() continues to be invoked periodically while > unmapping is paused. Should be console doing that, see > virtio_gpu_handle_gl_flushed().
Though, we're now blocking the render, and thus, virtio_gpu_process_cmdq() won't do anything while cmd is paused. I'll check that nothing else is missed and then won't add `async_unmap_in_progress` in v11, thanks! -- Best regards, Dmitry
