From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97ACFEE49B1 for ; Wed, 23 Aug 2023 04:46:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B82CE28003D; Wed, 23 Aug 2023 00:46:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B328E940007; Wed, 23 Aug 2023 00:46:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FA2B28003D; Wed, 23 Aug 2023 00:46:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8FA6D940007 for ; Wed, 23 Aug 2023 00:46:29 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4E8D58045E for ; Wed, 23 Aug 2023 04:46:29 +0000 (UTC) X-FDA: 81154133298.27.1F269FD Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf24.hostedemail.com (Postfix) with ESMTP id 62F0618001E for ; Wed, 23 Aug 2023 04:46:27 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="D/1uhAMB"; spf=pass (imf24.hostedemail.com: domain of tfiga@chromium.org designates 209.85.222.176 as permitted sender) smtp.mailfrom=tfiga@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692765987; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pbuj0UaWEA761fCPdddWt+wikwDEFpkNLnzTAhHNiDs=; b=qpE8zdiYqtqVdiXRVQqfvPK3DCHsTQPycxjVExeUTh54aIavNtN6Ahcs76q58cDSpvZLr9 WWPUgIIrmQG7Jr74iJ0GDvxqKuRyduX7RAFjz5OpmY1DIMn050eGkh5qOZeN+Hkoq217eM tUORzQHNCcHPmqQcB37RbrVoXhlgM6c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692765987; a=rsa-sha256; cv=none; b=PdGvouPjJVmgrxEQfdJr+e/jFTochuWb9kgdLADh/EwwdC36SouJ3/AFsi1kHowugitPMc 3ujzrIX+LBK0f/mZHtqcq08IMJXCr3wkN+JrBg5COPe3WDYDHYjUJctsh2OdMTzDLsFMVq XxFEZje2O11RCDbtilL1fRoupf+wpb4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="D/1uhAMB"; spf=pass (imf24.hostedemail.com: domain of tfiga@chromium.org designates 209.85.222.176 as permitted sender) smtp.mailfrom=tfiga@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-76dbe263c68so12308685a.0 for ; Tue, 22 Aug 2023 21:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1692765985; x=1693370785; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pbuj0UaWEA761fCPdddWt+wikwDEFpkNLnzTAhHNiDs=; b=D/1uhAMBMMYSvv227R9QNsh9n0F41mPXzvZeQQctwcKB8Lkiwnuj6gAhnssR72xkha AyzyPJ4cLH0iU2vV/ZVZujGM2DWIr1L7+0LfPaMHMjomDakkBXtJVTjPwk6ZOPHGRf89 QcGi8vkKxE1bmOAvTVOKADMlGbOw0rgfwOHD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692765985; x=1693370785; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pbuj0UaWEA761fCPdddWt+wikwDEFpkNLnzTAhHNiDs=; b=S/5cRBXre99CkbkKV+SB0JxSXx8WPocWjwubwFTa/mN/m2oM2hH0m/kSRnD8v6fc9+ 7oQrC90+3gILc/0B49CL02xRry0gstEVp6HT54aioaV+JXHhQZ1Rw7izloRms6dJrqPP 2pHw6jBwVTKkqt3eggosu4U6JlusBkcz0HnI8wEWuagtaOGSkb2mGkugcuLJ580E1jB1 4fP5L2gzlmsZL6zpZCoaPXMTvQhiYecWl0nR9p97f9U3xJnJ64dQXyUz/S04AL78Rrpq x3YnUvdzPSucXG0Hx1yuR4nojzgdMSbyJwNVtlXJbrjmbhwL7N8nhX9OQlRbi8lQaX0P sm+Q== X-Gm-Message-State: AOJu0Yy/w2w/C2m5+UdFLqcdmYWHFNGw3qmpWDSI0DgV05cvN22EWRGy 1sdxarw8RNGkWyHBlG7DJjR44LfX3qkmrM+Vg/kLLg== X-Google-Smtp-Source: AGHT+IHy1JIFS7mNQPghqEOivNmWLEr1ZMmi7c5Z3eyMLi3Ut2vLNZjw47ac1uU5azxIhZFIWXjJ7Q== X-Received: by 2002:a05:620a:178e:b0:76c:c1b8:5a4d with SMTP id ay14-20020a05620a178e00b0076cc1b85a4dmr13915367qkb.39.1692765985640; Tue, 22 Aug 2023 21:46:25 -0700 (PDT) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com. [209.85.219.45]) by smtp.gmail.com with ESMTPSA id r8-20020ac85e88000000b00410910c6164sm2353205qtx.50.2023.08.22.21.46.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Aug 2023 21:46:24 -0700 (PDT) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-649edb3a3d6so23165136d6.0 for ; Tue, 22 Aug 2023 21:46:24 -0700 (PDT) X-Received: by 2002:a05:6214:5493:b0:62d:f04b:b51 with SMTP id lg19-20020a056214549300b0062df04b0b51mr14567439qvb.29.1692765983989; Tue, 22 Aug 2023 21:46:23 -0700 (PDT) MIME-Version: 1.0 References: <029b982f-da62-4fa8-66c4-ab11a515574a@synaptics.com> In-Reply-To: <029b982f-da62-4fa8-66c4-ab11a515574a@synaptics.com> From: Tomasz Figa Date: Wed, 23 Aug 2023 13:46:07 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC]: shmem fd for non-DMA buffer sharing cross drivers To: Hsia-Jun Li Cc: linux-mm@kvack.org, dri-devel@lists.freedesktop.org, Linux Media Mailing List , hughd@google.com, akpm@linux-foundation.org, Simon Ser , Hans Verkuil , daniels@collabora.com, ayaka , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 62F0618001E X-Rspam-User: X-Stat-Signature: jusoapozsfw1qdqdo33hzi1bk8iuon61 X-Rspamd-Server: rspam03 X-HE-Tag: 1692765987-588220 X-HE-Meta: U2FsdGVkX18/ZgOMRoulX0m47gV1rSRzR1lFqTNIxk4yvf9NIMcVzET2A8J+KoH5LRjDDGd5dHC/Qk01/BEQtKqXKQD2blTUEzOuSDLK0uwjqaMVivTF92n1QPh5wjePP+rSMRIdCeBC4QX4pCfYBJ5wntNJcw/5jzL98rMN4xLibGlTR/MR8aH3HssU4z3wiRiBvLmUPiAHRmr0SRm7/YKNs3jL/8O104HB5X/tGTxg/wvSnqwzIu3yeeytx1Iec8uX20uYEuF1RIkF9eOgP/+c/voU8t8G5omu8nfKphqfY0S+tG5/0jp7v4fu8BA4foZqwuPoFvYQaBoor9cqKv/ClSiGFs16LXfrUJC4RmHgeD4CXFxTdkdA1P2Hx8vlEV1+gGQ+HtpcuXIdcDCF3PzRgCJhXsWNZQ9Bf8uYRSx1HxrxF8kjdWyl+GQ5UEnskmLufxVd02V+aJYh3q1GR3UuN5Qs+AD/WwWtKUYjMwP+5/L6sRaDnFt6/gebOxtuIb5UMk8L65q/n8fEfjxIGqX4BZdV+AWjJNkg6dOd1M8yTa2sB2Ta+v2UohJ4khiURzzlDSnFT8Vg3JI4+4lJQh4ceM8aF7qkfxM7/nKBYxlDdKKYUVNLq1obyBCIw3S8HF+3PcZh3X6fluIKDz8XOI5WGNgqjkdI0KS81MA653jac8KZvmlxkYYitXHqy7lw0Z6kxWp/2JW8JLF7soesLCOnJ3wUSae9yVBardstwO2bz7PSsUCXhCW4dcszA2Mw+x+N2flGaMqE6UPqVILOqWFU6VjvRywAx2uNaPXpNEHH2hIOGeXyan81zAyfHhNiVSBHvOFq5Qtsjv8S7ZfYzpcKITzwfrzia7pZRX+O52R6uXARyRjvRlBDGoSv84xLbyjqKsUW6eigLjRHceA9cTGE1P3ZNd5P7Vx0qKSGB2onjkAMsBNqc0dasFvokAtU27GAPe3NyaYi4V1QeW+ r+e1dxno qavPIGL+x2JsfxBf/LOLnIn5gpy17H2azBdUGRaXq2JXh/Gu1grPnnRz9WwXvYx3/FLlVZU1q1IQnSTTDj1Ta05FcnL8qb64Gt2XHw5x8Zwc0XvtJkWTuclgUgZP3PDIBewk21W6iCEGPaq0of3JJX8qzD+hQpQu1MQUgwJxD1pIKrx0RI+pDTaQbS20jxVuc4j2kunnRrg0HiEAgrz9Mq/KnW87oqmppCbqzZJRGDdWnmwhGxGjlCwcNZoy1fV5OLBLEQgUR/T8xQoTTXVKGwKKn/UPiwht8eBx1woArppl1JdC0kuPvMFROuxT8qz3pc8FRmjLrHuXkVHuZ5tEKExeigRnausN2pQZ3q1ofYHgU47T3Jf05WQW53lCoX5MriTWrawwhLYhF0g8aOFfQZxpvjmcC7bW2+NOuOByBSsH7L2I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Hsia-Jun, On Tue, Aug 22, 2023 at 8:14=E2=80=AFPM Hsia-Jun Li wrote: > > Hello > > I would like to introduce a usage of SHMEM slimier to DMA-buf, the major > purpose of that is sharing metadata or just a pure container for cross > drivers. > > We need to exchange some sort of metadata between drivers, likes dynamic > HDR data between video4linux2 and DRM. If the metadata isn't too big, would it be enough to just have the kernel copy_from_user() to a kernel buffer in the ioctl code? > Or the graphics frame buffer is > too complex to be described with plain plane's DMA-buf fd. > An issue between DRM and V4L2 is that DRM could only support 4 planes > while it is 8 for V4L2. It would be pretty hard for DRM to expend its > interface to support that 4 more planes which would lead to revision of > many standard likes Vulkan, EGL. Could you explain how a shmem buffer could be used to support frame buffers with more than 4 planes? > > Also, there is no reason to consume a device's memory for the content > that device can't read it, or wasting an entry of IOMMU for such data. That's right, but DMA-buf doesn't really imply any of those. DMA-buf is just a kernel object with some backing memory. It's up to the allocator to decide how the backing memory is allocated and up to the importer on whether it would be mapped into an IOMMU. > Usually, such a metadata would be the value should be written to a > hardware's registers, a 4KiB page would be 1024 items of 32 bits register= s. > > Still, I have some problems with SHMEM: > 1. I don't want thhe userspace modify the context of the SHMEM allocated > by the kernel, is there a way to do so? This is generally impossible without doing any of the two: 1) copying the contents to an internal buffer not accessible to the userspace, OR 2) modifying any of the buffer mappings to read-only 2) can actually be more costly than 1) (depending on the architecture, data size, etc.), so we shouldn't just discard the option of a simple copy_from_user() in the ioctl. > 2. Should I create a helper function for installing the SHMEM file as a f= d? We already have the udmabuf device [1] to turn a memfd into a DMA-buf, so maybe that would be enough? [1] https://elixir.bootlin.com/linux/v6.5-rc7/source/drivers/dma-buf/udmabu= f.c Best, Tomasz > > -- > Hsia-Jun(Randy) Li