[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virtio-dev][RFC PATCH v1 2/2] virtio-gpu: add the ability to export
Re: [virtio-dev][RFC PATCH v1 2/2] virtio-gpu: add the ability to export resources
Thu, 9 Jan 2020 17:28:34 -0800
I like the idea of having one central place in the kernel where
virtio-devices get their uuid from -- i.e, no separate VM specific,
device specific implementations calling into uuid_gen().
On Wed, Jan 8, 2020 at 3:20 AM David Stevens <address@hidden> wrote:
> > Is there a specific reason why you want the host pick the uuid? I would
> > let the guest define the uuid, i.e. move the uuid fields to
> > virtio_gpu_export_resource and scratch virtio_gpu_resp_export_resource.
> Sending the uuid in the original request doesn't really buy us
> anything, at least in terms of asynchronicity. The guest would still
> need to wait for the response to arrive before it could safely pass
> the uuid to any other virtio devices, to prevent a race where the
> import fails because it is processed before virtio-gpu processes the
> export. Perhaps this wouldn't be the case if we supported sharing
> fences between virtio devices, but even then, fences are more of a
> thing for the operation of a pipeline, not for the setup of a
> At that point, I think it's just a matter of aesthetics. I lean
> slightly towards returning the uuid from the host, since that rules
> out any implementation with the aforementioned race. That being said,
> if there are any specific reasons or preferences to assigning the uuid
> from the guest, I can switch to that direction.