OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [PATCH] virtio-gpu: add shared resource feature


  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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]