On 15/05/2023 13:38, Marc-André Lureau wrote: > However, I worry about using the new backend (calling GET_EDID) with an > older front-end/QEMU. It may just hang, since > vhost_user_gpu_handle_display() won't reply to unknown messages. That's > what PROTOCOL_FEATURES were meant for, iirc. Can you check? thanks
Indeed as you say, there is a hang with older qemu. >From what I see there are the generic protocol_features and also a vhost-user-gpu message for them. I assume it is so that we don't have to add vhost-user-gpu specific features to the generic set? In any case, the current vhost-user-gpu specific protocol_features negotiation happens too late to enable or disable virtio-gpu features (triggered by VHOST_USER_GPU_SET_SOCKET). I suppose we could move it earlier to the time the generic protocol_features are negotiated, through the callback hooks that already exist in the vhost-user layer (not implemented so far by vhost-user-gpu though). So I guess we could remove the protocol_features negotiation that is currently triggered by VHOST_USER_GPU_SET_SOCKET and use that to prevent exposing VIRTIO_GPU_F_EDID at all. Does that make sense? Otherwise, if we keep exposing VIRTIO_GPU_F_EDID and just not sending VHOST_USER_GPU_GET_EDID then the get_edid feature is not quite functional overall, which doesn't sound too great. Thanks Erico
