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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9345C433E0 for ; Tue, 16 Mar 2021 23:46:59 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F2A9F64E81 for ; Tue, 16 Mar 2021 23:46:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2A9F64E81 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fooishbar.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E2C456E44A; Tue, 16 Mar 2021 23:46:56 +0000 (UTC) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by gabe.freedesktop.org (Postfix) with ESMTPS id C95F66E44D for ; Tue, 16 Mar 2021 23:46:55 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id r15-20020a05600c35cfb029010e639ca09eso2399165wmq.1 for ; Tue, 16 Mar 2021 16:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NqcHEGtzYszUnRQT2utO15aI8o8Zz2gtnHf8uFMKcXQ=; b=TdoVmwoke9Wc0r7e91+zsv2NJeZwaQm2XSO4zY8/gn5VbXIAFFwAd7cRLxx5oAm0mR NlCpzJXXIQTUoSMwOgCT3aSGCexkdUhQ6hVrIXw/Jf99QruQ9UvEUeZ6ReUMKCzOo53f CN5/hQB53LD0ognh08/uWASWDkgOKJ0m1OK6MdLuX1EO5/BsCs1krvTVfiDVrdWOMFVv bIjEUKVPtnfyPDMraEP3EufutjVVw/6vQhU2Zf/CAzVUUFt2LqrUK8ExMDEvRE24if7q 3IqSxHuhfEflZYIpBcm3iNOwRlREprgR94jsZiKqfJ/0hUAIG9Ot3kBCUHmThywXSrJ6 kSAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NqcHEGtzYszUnRQT2utO15aI8o8Zz2gtnHf8uFMKcXQ=; b=UdFHEkZkoXNc69xd7eLPpc853AHzPVO6/o1fRUfoKH14tQBXo/egsGKxpUelT1l2+z ODhd/u+9TaqD1YO+cUZv7sz5nlO1E4eAvd75yr8PjUDrcuk6wJdVpnXou4fKucMkvyf4 dy+NMNsklCN89T/WKkPu6XygoTnZ0JNNqaMnoph8ZQxnm+1b8gpiljkJHYSL12nEPIwc 0sJVw6fWKfWrx40j/8J2xUxndYbdxA0M6bXOeCshitRLBVHxzf9ELKEfvj0CVjxaPW56 aFoOcQuPmgzyOKlywJ9f4jK1y+6S4zIU6x1VjDG82E0Xurih3ubUcCyIl6KlCNYiAfRs I6hA== X-Gm-Message-State: AOAM532pW1K3A9tC10c37HQRJ9Y97zGWd7+R1eMurIx9TdJvo8kN7zL9 nKCqsBLe/o6uzVxT+5FznX4sQCJ00eEG3VvtSjA+HA== X-Google-Smtp-Source: ABdhPJx6Gk+6ZL58g8FW0I4fZHd0xlCol3zJvk21YJfOqzSRNNVgscREqLFh0+C1aegL60MN9CPmDzyayiUfaySytw0= X-Received: by 2002:a7b:c047:: with SMTP id u7mr1061018wmc.98.1615938414203; Tue, 16 Mar 2021 16:46:54 -0700 (PDT) MIME-Version: 1.0 References: <20210302204132.12058-1-manasi.d.navare@intel.com> <20210303104744.2c064f09@eldfell> <20210303204433.GA15819@labuser-Z97X-UD5H> <20210304104223.6b3490bc@eldfell> <20210309005252.GA27491@labuser-Z97X-UD5H> <20210309111350.3be0543f@eldfell> In-Reply-To: From: Daniel Stone Date: Tue, 16 Mar 2021 23:46:38 +0000 Message-ID: Subject: Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true To: Daniel Vetter X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , intel-gfx , dri-devel , Daniel Stone Content-Type: multipart/mixed; boundary="===============1300844170==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1300844170== Content-Type: multipart/alternative; boundary="00000000000028646005bdaffbeb" --00000000000028646005bdaffbeb Content-Type: text/plain; charset="UTF-8" On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen > wrote: > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > Yeah. We can _never_ generate externally-visible completion events. We can later fail to enable the stolen CRTC - because trying to enable new things can fail for any reason whatsoever - but we can't generate spurious completion events, as doing so falls into the uncanny valley. If the kernel is doing clever things behind userspace's back - such as stealing planes or CRTCs - then userspace can never know about it, apart from failing to enable those resources later. The kernel can either never do anything clever (and make userspace bind them both together), or be extremely clever (by hiding the entire details from userspace), but it cannot choose the halfway house of doing clever things behind userspace's back (such as stealing new CRTCs) whilst also exposing all those details to userspace (such as delivering spurious completion events for resources userspace never requested to be programmed). Cheers, Daniel --00000000000028646005bdaffbeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 16 Mar 2021 at 2= 1:35, Daniel Vetter <daniel@ffwll.ch<= /a>> wrote:
On Tue, Mar 9, 2021 at 10:14 AM Pekka Paal= anen <ppaalanen= @gmail.com> wrote:
> On Mon, 8 Mar 2021 16:52:58 -0800
> "Navare, Manasi" <manasi.d.navare@intel.com> wrote:
> &g= t; Hmm well after the actual real commit, since the second crtc is stolen > > even though it is not being used for the display output, it is > > used for joiner so the uapi.enable will be true after the real co= mmit.
> >
> > so actually the assertion would fail in this case.
> >
> > @Ville @Danvet any suggestions here in that case?

That is very bad. We can't frob uapi state like that. I think that
calls for even more checks to make sure kms drivers who try to play
clever games don't get it wrong, so we probably need to check uapi
enable and active state in another mask before/after ->atomic_check
too. Or something like that.

Yeah. We c= an _never_ generate externally-visible completion events. We can later fail= to enable the stolen CRTC - because trying to enable new things can fail f= or any reason whatsoever - but we can't generate spurious completion ev= ents, as doing so falls into the uncanny valley.

I= f the kernel is doing clever things behind userspace's back - such as s= tealing planes or CRTCs - then userspace can never know about it, apart fro= m failing to enable those resources later. The kernel can either never do a= nything clever (and make userspace bind them both together), or be extremel= y clever (by hiding the entire details from userspace), but it cannot choos= e the halfway house of doing clever things behind userspace's back (suc= h as stealing new CRTCs) whilst also exposing all those details to userspac= e (such as delivering spurious completion events for resources userspace ne= ver requested to be programmed).

Cheers,
Daniel=C2=A0
--00000000000028646005bdaffbeb-- --===============1300844170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1300844170==-- 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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42A02C433DB for ; Tue, 16 Mar 2021 23:47:03 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E387864EF2 for ; Tue, 16 Mar 2021 23:47:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E387864EF2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fooishbar.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 24D766E44D; Tue, 16 Mar 2021 23:46:57 +0000 (UTC) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by gabe.freedesktop.org (Postfix) with ESMTPS id BF7346E44A for ; Tue, 16 Mar 2021 23:46:55 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id n11-20020a05600c4f8bb029010e5cf86347so4594313wmq.1 for ; Tue, 16 Mar 2021 16:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NqcHEGtzYszUnRQT2utO15aI8o8Zz2gtnHf8uFMKcXQ=; b=TdoVmwoke9Wc0r7e91+zsv2NJeZwaQm2XSO4zY8/gn5VbXIAFFwAd7cRLxx5oAm0mR NlCpzJXXIQTUoSMwOgCT3aSGCexkdUhQ6hVrIXw/Jf99QruQ9UvEUeZ6ReUMKCzOo53f CN5/hQB53LD0ognh08/uWASWDkgOKJ0m1OK6MdLuX1EO5/BsCs1krvTVfiDVrdWOMFVv bIjEUKVPtnfyPDMraEP3EufutjVVw/6vQhU2Zf/CAzVUUFt2LqrUK8ExMDEvRE24if7q 3IqSxHuhfEflZYIpBcm3iNOwRlREprgR94jsZiKqfJ/0hUAIG9Ot3kBCUHmThywXSrJ6 kSAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NqcHEGtzYszUnRQT2utO15aI8o8Zz2gtnHf8uFMKcXQ=; b=R5qZyi+9kNZTU1fWNIN+hdboyUSK9MhrJTt2BxRln/YF+lPkENAONVyTeYzHPQGF/f JSghQFaHNAW6ykaZfx/b3BZpMo3nQMsKOgUC+2MMdR0rUx2Qhg7FaRbHf1geyriB/YfF MEUgzgOrAECeLNtdlO7d06nWrjqr5ngREGgQ0g2ja9m9aZx5LtLFd61UhorUxQ+L2oDq br/Y2bDy99DQ0mPuducA3oZQfBBnQMFH6dL3kozLni81lKvBYn5ttJh0yECEXSsyL4SW yDB1DMjkvA9sraBS4mHoGD3sgHnThftk/XeAU51dyjwOFYzM4SZJOc9o//EsXJN9h6O1 CL1w== X-Gm-Message-State: AOAM531uiIKoh0YlD1lsERUS8pkvex34U0xDC/lw6m7pQMawMTq6G94A JvhFEiouSWmdZJiHfOH28TAK9l9ijrcTYOw50e4+Og== X-Google-Smtp-Source: ABdhPJx6Gk+6ZL58g8FW0I4fZHd0xlCol3zJvk21YJfOqzSRNNVgscREqLFh0+C1aegL60MN9CPmDzyayiUfaySytw0= X-Received: by 2002:a7b:c047:: with SMTP id u7mr1061018wmc.98.1615938414203; Tue, 16 Mar 2021 16:46:54 -0700 (PDT) MIME-Version: 1.0 References: <20210302204132.12058-1-manasi.d.navare@intel.com> <20210303104744.2c064f09@eldfell> <20210303204433.GA15819@labuser-Z97X-UD5H> <20210304104223.6b3490bc@eldfell> <20210309005252.GA27491@labuser-Z97X-UD5H> <20210309111350.3be0543f@eldfell> In-Reply-To: From: Daniel Stone Date: Tue, 16 Mar 2021 23:46:38 +0000 Message-ID: To: Daniel Vetter Subject: Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , Pekka Paalanen , intel-gfx , dri-devel , Daniel Stone Content-Type: multipart/mixed; boundary="===============2039096515==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============2039096515== Content-Type: multipart/alternative; boundary="00000000000028646005bdaffbeb" --00000000000028646005bdaffbeb Content-Type: text/plain; charset="UTF-8" On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen > wrote: > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > Yeah. We can _never_ generate externally-visible completion events. We can later fail to enable the stolen CRTC - because trying to enable new things can fail for any reason whatsoever - but we can't generate spurious completion events, as doing so falls into the uncanny valley. If the kernel is doing clever things behind userspace's back - such as stealing planes or CRTCs - then userspace can never know about it, apart from failing to enable those resources later. The kernel can either never do anything clever (and make userspace bind them both together), or be extremely clever (by hiding the entire details from userspace), but it cannot choose the halfway house of doing clever things behind userspace's back (such as stealing new CRTCs) whilst also exposing all those details to userspace (such as delivering spurious completion events for resources userspace never requested to be programmed). Cheers, Daniel --00000000000028646005bdaffbeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 16 Mar 2021 at 2= 1:35, Daniel Vetter <daniel@ffwll.ch<= /a>> wrote:
On Tue, Mar 9, 2021 at 10:14 AM Pekka Paal= anen <ppaalanen= @gmail.com> wrote:
> On Mon, 8 Mar 2021 16:52:58 -0800
> "Navare, Manasi" <manasi.d.navare@intel.com> wrote:
> &g= t; Hmm well after the actual real commit, since the second crtc is stolen > > even though it is not being used for the display output, it is > > used for joiner so the uapi.enable will be true after the real co= mmit.
> >
> > so actually the assertion would fail in this case.
> >
> > @Ville @Danvet any suggestions here in that case?

That is very bad. We can't frob uapi state like that. I think that
calls for even more checks to make sure kms drivers who try to play
clever games don't get it wrong, so we probably need to check uapi
enable and active state in another mask before/after ->atomic_check
too. Or something like that.

Yeah. We c= an _never_ generate externally-visible completion events. We can later fail= to enable the stolen CRTC - because trying to enable new things can fail f= or any reason whatsoever - but we can't generate spurious completion ev= ents, as doing so falls into the uncanny valley.

I= f the kernel is doing clever things behind userspace's back - such as s= tealing planes or CRTCs - then userspace can never know about it, apart fro= m failing to enable those resources later. The kernel can either never do a= nything clever (and make userspace bind them both together), or be extremel= y clever (by hiding the entire details from userspace), but it cannot choos= e the halfway house of doing clever things behind userspace's back (suc= h as stealing new CRTCs) whilst also exposing all those details to userspac= e (such as delivering spurious completion events for resources userspace ne= ver requested to be programmed).

Cheers,
Daniel=C2=A0
--00000000000028646005bdaffbeb-- --===============2039096515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============2039096515==--