From: Neil Armstrong <narmstrong@baylibre.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: "mjourdan@baylibre.com" <mjourdan@baylibre.com>,
Simon Ser <contact@emersion.fr>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Kevin Hilman <khilman@baylibre.com>,
"linux-amlogic@lists.infradead.org"
<linux-amlogic@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
Date: Fri, 27 Mar 2020 15:14:46 +0100 [thread overview]
Message-ID: <7acc751d-161f-af9c-d896-b4e43fb9b0ac@baylibre.com> (raw)
In-Reply-To: <20200326113632.6585cf7b@eldfell.localdomain>
[-- Attachment #1.1.1: Type: text/plain, Size: 5304 bytes --]
Hi,
On 26/03/2020 10:36, Pekka Paalanen wrote:
> On Wed, 25 Mar 2020 17:18:15 +0100
> Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Hi,
>>
>> On 25/03/2020 14:49, Pekka Paalanen wrote:
>>> On Wed, 25 Mar 2020 11:24:15 +0100
>>> Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 25/03/2020 10:04, Simon Ser wrote:
>>>>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>>
>>>>>> Amlogic uses a proprietary lossless image compression protocol and format
>>>>>> for their hardware video codec accelerators, either video decoders or
>>>>>> video input encoders.
>>>>>>
>>>>>> This introduces the Scatter Memory layout, means the header contains IOMMU
>>>>>> references to the compressed frames content to optimize memory access
>>>>>> and layout.
>>>>>>
>>>>>> In this mode, only the header memory address is needed, thus the content
>>>>>> memory organization is tied to the current producer execution and cannot
>>>>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
>>>>>> modifier.
>>>>>
>>>>> I don't think this is suitable for modifiers. User-space relies on
>>>>> being able to copy a buffer from one machine to another over the
>>>>> network. It would be pretty annoying for user-space to have a blacklist
>>>>> of modifiers that don't work this way.
>>>>>
>>>>> Example of such user-space:
>>>>> https://gitlab.freedesktop.org/mstoeckl/waypipe/
>>>>>
>>>>
>>>> I really understand your point, but this is one of the use-cases we need solve.
>>>> This is why I split the fourcc patch and added an explicit comment.
>>>>
>>>> Please point me a way to display such buffer, the HW exists, works like that and
>>>> it's a fact and can't change.
>>>>
>>>> It will be the same for secure zero-copy buffers we can't map from userspace, but
>>>> only the HW decoder can read/write and HW display can read.
>>>
>>> The comparison to secure buffers is a good one.
>>>
>>> Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
>>> meaningfully mmappable to CPU always / sometimes / never /
>>> varies-and-cannot-know?
>>
>> mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never.
>>
>> So yeah, these should not be mmappable since not meaningful.
>
> Ok. So we have a modifier that means there is no point in even trying to
> mmap the buffer.
>
> Not being able to mmap automatically makes things like waypipe not be
> able to work on the buffer, so the buffer cannot be replicated over a
> network, hence there is no compatibility issue. However, it still
> leaves the problem that, since waypipe is "just" a message relay that
> does not participate in the protocol really, the two end points might
> still negotiate to use a modifier that waypipe cannot handle.
Not mmapable won't be limited to this kind of buffer, or secure, any DMA-BUF
provider can decide to disable mmaping, so waypipe should work with this
whatever this discussion goes to.
>
> Secure buffers have the same problem: by definition, one must not be
> able to replicate the buffer elsewhere.
>
> To me it seems there needs to be a way to identify buffers that cannot
> be mmapped. mmap() failing is obvious, but in waypipe's case it is too
> late - the end points have already negotiated the formats and modifiers
> and they cannot handle failures afterwards.
The AFAIK last open question was on this thread:
https://lore.kernel.org/dri-devel/d6f8092d-9f90-d5ff-2ab3-b1867f8f5700@ti.com/
But it was more like, how the consumer driver knows the buffer is secure.
Daniel, is there something new ?
>
>>>
>>> Maybe this type should be handled similar to secure buffers, with the
>>> exception that they are not actually secured but only mostly
>>> inaccessible. Then again, I haven't looked at any of the secure buffer
>>> proposals.
>>
>> Actually, the Amlogic platforms offers secure video path using these exact
>> modifiers, AFAIK it doesn't support the NV12 dual-write output in secure.
>>
>> AFAIK last submission is from AMD, and it doesn't talk at all about mmapability
>> of the secure BOs.
>
> To me, a secure buffer concept automatically implies that there cannot
> be CPU access to it. The CPU is not trusted, right? Not even the kernel.
> I would assume secure implies no mmap. So I wonder, how does the secure
> buffers proposal manage userspace like waypipe?
None, as I said, waypipe whould handle non mmapable buffers, by asking
for a different modifier set, or sending a gray buffer with a llama
instead.
>
> Or, is the secure buffer proposal allowing mmap, but the content is
> indecipherable? Maybe they shouldn't allow mmap?
Definitely, you'll have an HW bus error if you access a secure buffer,
otherwise the security is weak. A bus firewall is the common way to handle
such secure buffers.
>
> I think much of the criticism against this modifier should also be
> presented to a secure buffers proposal and see how that turns out. If
> they have the same problem, maybe you could use their solution?
Sure, but seems there is no consensus for the compositor side.
Neil
>
>
> Thanks,
> pq
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-27 14:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode Neil Armstrong
2020-03-25 8:50 ` [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout Neil Armstrong
2020-03-25 9:04 ` Simon Ser
2020-03-25 10:24 ` Neil Armstrong
2020-03-25 13:49 ` Pekka Paalanen
2020-03-25 16:18 ` Neil Armstrong
2020-03-26 9:36 ` Pekka Paalanen
2020-03-27 14:14 ` Neil Armstrong [this message]
2020-03-30 14:41 ` Pekka Paalanen
2020-03-25 8:50 ` [PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout Neil Armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7acc751d-161f-af9c-d896-b4e43fb9b0ac@baylibre.com \
--to=narmstrong@baylibre.com \
--cc=contact@emersion.fr \
--cc=dri-devel@lists.freedesktop.org \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjourdan@baylibre.com \
--cc=ppaalanen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).