RE: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Gurchetan Singh <gurchetansingh@xxxxxxxxxxxx>
> Sent: Tuesday, April 13, 2021 8:58 AM
> To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
> Cc: Kasireddy, Vivek <vivek.kasireddy@xxxxxxxxx>; ML dri-devel <dri-
> devel@xxxxxxxxxxxxxxxxxxxxx>; Zhang, Tina <tina.zhang@xxxxxxxxx>
> Subject: Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)
> 
> 
> 
> On Fri, Apr 9, 2021 at 12:48 AM Gerd Hoffmann <mailto:kraxel@xxxxxxxxxx>
> wrote:
>   Hi,
> 
> > > IIRC the VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag means that the host
> *can*
> > > create a shared mapping (i.e. the host seeing guest-side changes without
> > > explicit transfer doesn't cause problems for the guest).  It doesn not
> > > mean the host *must* create a shared mapping (note that there is no
> > > negotiation whenever the host supports shared mappings or not).
> > >
> >
> > VIRTGPU_BLOB_FLAG_USE_SHAREABLE means guest userspace intends to
> share the
> > blob resource with another virtgpu driver instance via
> drmPrimeHandleToFd.
> > It's a rough analogue to VkExportMemoryAllocateInfoKHR or
> > PIPE_BIND_USE_SHARED.
> 
> Oh.  My memory was failing me then.  We should *really* clarify the spec
> for BLOB_MEM_GUEST.
> 
> So shared mappings are allowed for all BLOB_MEM_GUEST resources, right?
> 
> The guest iovecs are always shared with the host, so they may be copied
> to/from directly depending on the operation.  In the case of
> RESOURCE_FLUSH + BLOB_MEM_GUEST, it could be a copy from the guest
> iovecs to the host framebuffer [host framebuffer != host shadow memory].
> 
> 
> > > So the transfer calls are still needed, and the host can decide to
> > > shortcut them in case it can create a shared mapping.  In case there is
> > > no shared mapping (say due to missing udmabuf support) the host can
> > > fallback to copying.
> >
> > Transfers are a bit under-defined for BLOB_MEM_GUEST.  Even without
> udmabuf
> > on the host, there is no host side resource for guest-only blobs?  Before
> > blob resources, the dumb flow was:
> >
> > 1) update guest side resource
> > 2) TRANSFER_TO_HOST_2D to copy guest side contents to host side private
> > resource [Pixman??]
> > 3) RESOURCE_FLUSH to copy the host-side contents to the framebuffer and
> > page-flip
> 
> Yes.
> 
> > At least for crosvm, this is possible:
> >
> > 1) update guest side resource
> > 2) RESOURCE_FLUSH to copy the guest-side contents to the framebuffer and
> > pageflip
> >
> > With implicit udmabuf, it may be possible to do this:
> >
> > 1) update guest side resource
> > 2) RESOURCE_FLUSH to page-flip
> >
> > > So I think crosvm should be fixed to not consider transfer commands for
> > > VIRTGPU_BLOB_MEM_GUEST resources an error.
> >
> > It's a simple change to make and we can definitely do it, if TRANSFER_2D is
> > helpful for the QEMU case.  I haven't looked at the QEMU side patches.
> 
> Well, we have two different cases:
> 
>   (1) No udmabuf available.  qemu will have a host-side shadow then and
>       the workflow will be largely identical to the non-blob resource
>       workflow.
> 
> I think this is the key difference.  With BLOB_MEM_GUEST, crosvm can only
> have a guest side iovecs and no host-side shadow memory.  With
> BLOB_MEM_GUEST_HOST3D, host-side shadow memory will exist.
> 
> I guess it boils down the Pixman dependency.  crosvm sits right on top of
> display APIs (X, wayland) rather than having intermediary layers.  Adding a
> new Pixman API takes time too.
> 
> There's a bunch of options:
> 
> 1) Don't use BLOB_MEM_GUEST dumb buffers in 3D mode.
> 2) virglrenderer or crosvm modified to implicitly ignore
> TRANSFER_TO_HOST_2D for BLOB_MEM_GUEST when in 3D mode.
> 3) It's probably possible to create an implicit udmabuf
> for RESOURCE_CREATE_2D resources and ignore the transfer there too.  The
> benefit of this is TRANSFER_TO_HOST_2D makes a ton of sense for non-blob
> resources.  No kernel side change needed here, just QEMU.
> 4) modify QEMU display integration
> 
> I would choose (1) since it solves the log spam problem and it advances blob
> support in QEMU.  Though I leave the decision to QEMU devs.
> 
> 
>   (2) With udmabuf support.  qemu can create udmabufs for the resources,
>       mmap() the dmabuf to get a linear mapping, create a pixman buffer
>       backed by that dmabuf (no copying needed then).  Depending on
>       capabilities pass either the pixman image (gl=off) or the dmabuf
>       handle (gl=on) to the UI code to actually show the guest display.
> 
> The guest doesn't need to know any of this, it'll just send transfer and
> flush commands.  In case (1) qemu must process the transfer commands and
> for case (2) qemu can simply ignore them.
> 
> > For the PCI-passthrough + guest blob case, the end goal is to share it with
> > the host compositor.  If there is no guarantee the guest memory can be
> > converted to an OS-handle (to share with the host compositor), then I think
> > the guest user space should fallback to another technique involving
> > memcpy() to share the memory.
> 
> This is what happens today (using non-blob resources).
> 
> > So essentially, thinking for two new protocol additions:
> >
> > F_CREATE_GUEST_HANDLE (or F_HANDLE_FROM_GUEST) --> means an OS-
> specific
> > udmabuf-like mechanism exists on the host.
> >
> > BLOB_FLAG_CREATE_GUEST_HANDLE (or
> BLOB_FLAG_HANDLE_FROM_GUEST)--> tells
> > host userspace "you must create a udmabuf" [or OS-specific equivalent]
> upon
> > success
> 
> Again:  Why do we actually need that?  Is there any benefit other than
> the guest knowing it doesn't need to send transfer commands?
> I see the whole udmabuf thing as a host-side performance optimization
> and I think this should be fully transparent to the guest as the host
> can easily just ignore the transfer commands.
> 
> So the use case I'm most interested in (and Vivek/Tina?) is tiled/compressed
> udmabufs, so they may be eventually shared with the host compositor via the
> DRM modifier API.
Hi,

Yes, eventually, we would like to have the tiled/compressed framebuffers shared by the udmabufs mechanism.

BR,
Tina
> 
> Transfers to linear udmabufs make sense.  Maybe transfers to
> tiled/compressed udmabufs shouldn't even be attempted.
> 
> It's a complicated case with many ambiguities, especially with PCI
> passthrough involved.  Explicit tiled/compressed udmabufs are just an idea,
> will have to think more about it / have some proof of concept [with virgl and
> PCI passthrough], before making any concrete proposals.  Will keep your idea
> of just ignoring transfers on the host in mind.
> 
> Given we batch commands
> the extra commands don't lead to extra context switches, so there
> shouldn't be much overhead.
> 
> If we really want make the guest aware of the hosts udmabuf state I
> think this should be designed the other way around:  Add some way for
> the host to tell the guest transfer commands are not needed for a
> specific BLOB_MEM_GUEST resource.
> 
> take care,
>   Gerd
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux