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. -- Best regards, Dmitry
