On 10/22/24 15:37, Dmitry Osipenko wrote:
> On 10/22/24 08:11, Akihiko Odaki wrote:
>> On 2024/10/19 6:31, Dmitry Osipenko wrote:
>>> On 10/18/24 08:28, Akihiko Odaki wrote:
>>>>> +static void virgl_write_context_fence(void *opaque, uint32_t ctx_id,
>>>>> + uint32_t ring_idx, uint64_t
>>>>> fence)
>>>>> +{
>>>>> + VirtIOGPU *g = opaque;
>>>>
>>>> What about taking the BQL here instead of having a QEMUBH?
>>>
>>> That will block virglrenderer thread writing the fence, which in turns
>>> might block other virglrenderer threads.
>>
>> Looking at virglrenderer's source code, the thread writing the fence is
>> the only thread it creates. Otherwise virglrenderer's code should be
>> executed only in the QEMU thread calling virglrenderer's functions,
>> which always holds the BQL. So taking the BQL here will not interfere
>> with another thread.
>
> There are other problems with that BQL approach:
>
> 1. virgl_renderer_context_destroy() is executed from QEMU's main-loop
> and it will terminate the virglrenderer's fence-sync threads which at
> the same time will take the same BQL if fence fires while VM is shutting
> down and then this condition will result in a deadlock.
I mixed up virgl_renderer_context_destroy() with
virgl_renderer_cleanup() here, but actually
virgl_renderer_context_destroy() will have the same deadlock issue.
--
Best regards,
Dmitry
