Hi, > If the following scenario happens: > > 1) Driver sends RESOURCE_CREATE_2D shared request > 2) Driver sends ATTACH_BACKING request > 3) Device creates a shared resource > 4) Driver sends SET_SCANOUT request > 5) Device sends shared resource to display > 6) Driver sends DETACH_BACKING request
Hmm, I think you can crash the current qemu code that way (didn't test though). I think the proper solution would be to return -EBUSY on the DETACH_BACKING request. Guess I'll add a new error code for that. > > +Otherwise the shared resources are used like normal resources. > > +Especially the driver must send explicit VIRTIO_GPU_CMD_TRANSFER_* > > +commands to the device for both normal and shared resources. Reason: > > +The device might have to flush caches. > > Can we make this spec stronger to avoid to avoid transfers all the > time (i.e, in virtio_gpu_update_dumb_bo)? > > drm_gem_shmem_* helpers seem to use WC buffers, and dumb buffers are > traditionally WC as well. If we mandate the host ("device?" here) > must properly clean caches at creation time, it may be possible to > avoid hypercalls for 2D_SHARED resources. I think we can do 90% of that optimization without changing the protocol. Display updates typically involve multiple commands. A transfer, possibly a set-scanout (when page-flipping), finally flush. The driver can first queue all commands, then notify the host, so we will have only one vmexit per display update instead of one vmexit per command. > > The device MAY also choose to > > +not create mapping for the shared resource. Especially for small > > +resources it might be more efficient to just copy the data instead of > > +establishing a shared mapping. > > Should the device send a response code (OK_SHARED} to inform the > driver that the resource is shared? Is there a good reason why the driver should be aware of that? I'd prefer to make that an internal implementation detail of the device and not inform the guest. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org