Hi Erico On Wed, May 17, 2023 at 8:09 PM Erico Nunes <ernu...@redhat.com> wrote:
> 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? > > Wouldn't this work? If VIRTIO_GPU_F_EDID is set and during protocol_features the GET_EDID feature is not negotiated, exit the gpu backend with an error. 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 > > -- Marc-André Lureau
