Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751278AbdLZST3 (ORCPT ); Tue, 26 Dec 2017 13:19:29 -0500 Received: from mga01.intel.com ([192.55.52.88]:22342 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbdLZST2 (ORCPT ); Tue, 26 Dec 2017 13:19:28 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,461,1508828400"; d="scan'208";a="161889096" Date: Tue, 26 Dec 2017 10:19:27 -0800 From: Matt Roper To: Dongwon Kim , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "Potrola, MateuszX" , "dri-devel@lists.freedesktop.org" , Intel Graphics Development , intel-gvt-dev@lists.freedesktop.org Subject: Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv Message-ID: <20171226181927.GM5820@mdroper-desk.amr.corp.intel.com> References: <1513711816-2618-1-git-send-email-dongwon.kim@intel.com> <20171219232731.GA6497@downor-Z87X-UD5H> <20171220095957.GL26573@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171220095957.GL26573@phenom.ffwll.local> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5394 Lines: 118 On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: > > I forgot to include this brief information about this patch series. > > > > This patch series contains the implementation of a new device driver, > > hyper_dmabuf, which provides a method for DMA-BUF sharing across > > different OSes running on the same virtual OS platform powered by > > a hypervisor. > > > > Detailed information about this driver is described in a high-level doc > > added by the second patch of the series. > > > > [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing > > > > I am attaching 'Overview' section here as a summary. > > > > ------------------------------------------------------------------------------ > > Section 1. Overview > > ------------------------------------------------------------------------------ > > > > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual > > achines (VMs), which expands DMA-BUF sharing capability to the VM environment > > where multiple different OS instances need to share same physical data without > > data-copy across VMs. > > > > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the > > exporting VM (so called, “exporter”) imports a local DMA_BUF from the original > > producer of the buffer, then re-exports it with an unique ID, hyper_dmabuf_id > > for the buffer to the importing VM (so called, “importer”). > > > > Another instance of the Hyper_DMABUF driver on importer registers > > a hyper_dmabuf_id together with reference information for the shared physical > > pages associated with the DMA_BUF to its database when the export happens. > > > > The actual mapping of the DMA_BUF on the importer’s side is done by > > the Hyper_DMABUF driver when user space issues the IOCTL command to access > > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and > > exporting driver as is, that is, no special configuration is required. > > Consequently, only a single module per VM is needed to enable cross-VM DMA_BUF > > exchange. > > So I know that most dma-buf implementations (especially lots of importers > in drivers/gpu) break this, but fundamentally only the original exporter > is allowed to know about the underlying pages. There's various scenarios > where a dma-buf isn't backed by anything like a struct page. > > So your first step of noodling the underlying struct page out from the > dma-buf is kinda breaking the abstraction, and I think it's not a good > idea to have that. Especially not for sharing across VMs. > > I think a better design would be if hyper-dmabuf would be the dma-buf > exporter in both of the VMs, and you'd import it everywhere you want to in > some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always > in control of the pages, and a lot of the troubling forwarding you > currently need to do disappears. I think one of the main driving use cases here is for a "local" graphics compositor inside the VM to accept client buffers from unmodified applications and then pass those buffers along to a "global" compositor running in the service domain. This would allow the global compositor to composite applications running in different virtual machines (and possibly running under different operating systems). If we require that hyper-dmabuf always be the exporter, that complicates things a little bit since a buffer allocated via regular interfaces (GEM ioctls or whatever) wouldn't be directly transferrable to the global compositor. For graphics use cases like this, we could probably hide a lot of the details by modifying/replacing the EGL implementation that handles the details of buffer allocation. However if we have applications that are themselves just passing along externally-allocated buffers (e.g., images from a camera device), we'd probably need to modify those applications and/or the drivers they get their content from. Matt > > 2nd thing: This seems very much related to what's happening around gvt and > allowing at least the host (in a kvm based VM environment) to be able to > access some of the dma-buf (or well, framebuffers in general) that the > client is using. Adding some mailing lists for that. > -Daniel > > > > > ------------------------------------------------------------------------------ > > > > There is a git repository at github.com where this series of patches are all > > integrated in Linux kernel tree based on the commit: > > > > commit ae64f9bd1d3621b5e60d7363bc20afb46aede215 > > Author: Linus Torvalds > > Date: Sun Dec 3 11:01:47 2017 -0500 > > > > Linux 4.15-rc2 > > > > https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v3 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795