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 <stevensd@xxxxxxxxxxxx> 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 > pipeline. > > 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. > > -David
