From: Marc Zyngier <maz@kernel.org> To: Sumit Garg <sumit.garg@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>, Devicetree List <devicetree@vger.kernel.org>, Linux Doc Mailing List <linux-doc@vger.kernel.org>, Jerome Forissier <jerome@forissier.org>, Etienne Carriere <etienne.carriere@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, Rob Herring <robh+dt@kernel.org>, Jonathan Corbet <corbet@lwn.net>, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH v2 0/7] Asynchronous notifications from secure world Date: Tue, 06 Jul 2021 11:36:17 +0100 [thread overview] Message-ID: <87czrv91b2.wl-maz@kernel.org> (raw) In-Reply-To: <CAFA6WYMSAM2MDOXnhjuZFov3BtF8-nihZRUpR8ciUWsL4_nCWA@mail.gmail.com> On Tue, 06 Jul 2021 08:25:26 +0100, Sumit Garg <sumit.garg@linaro.org> wrote: > > On Thu, 17 Jun 2021 at 11:40, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > Hi Sumit, > > > > On Thu, Jun 17, 2021 at 6:33 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Hi Jens, > > > > > > On Wed, 16 Jun 2021 at 16:07, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > > > > > Hi all, > > > > > > > > This adds support for asynchronous notifications from OP-TEE in secure > > > > world to the OP-TEE driver. This allows a design with a top half and bottom > > > > half type of driver where the top half runs in secure interrupt context and > > > > a notifications tells normal world to schedule a yielding call to do the > > > > bottom half processing. > > > > > > > > An interrupt is used to notify the driver that there are asynchronous > > > > notifications pending. > > > > > > > > > > It looks like a nice feature. I would like to get hands on with this. > > > Can I test this feature on Qemu? > > > > Absolutely, you can get this into the normal OP-TEE development repo setup with: > > repo init -u https://github.com/OP-TEE/manifest.git -m default.xml > > repo sync > > Update optee_os with > > https://github.com/jenswi-linaro/optee_os/tree/async_notif_v2 > > Update linux with https://github.com/jenswi-linaro/linux-1/tree/async_notif_v2 > > cd build > > make all -j... > > make run-only > > > > If you type anything at the secure console you'll notice how it > > changes behaviour once the Linux kernel has booted. > > > > Thanks for sharing instructions as I now got some time to test and > deep dive into this feature. It looks like a pretty useful feature to > realize interrupt support in the secure world in its true sense. This > feature works for me as per your instructions. > > I could recognise it's requirement from the time while I was playing > with secure timer interrupt support for OP-TEE RNG driver on > Developerbox. In that case I had to strip down the secure interrupt > handler to a minimum that would just collect entropy and dump into the > secure buffer. But with asynchronous notifications support, I could > add more functionality like entropy health tests in the bottom half > instead of doing those health tests while retrieving entropy from the > secure world. > > Given that, have you explored the possibility to leverage SGI rather > than a platform specific SPI for notifying the normal world? If it's > possible to leverage Architecture specific SGI for this purpose then I What does "Architecture specific SGI" mean? > think this feature will come automatically enabled for every platform > without the need to reserve a platform specific SPI. That old chestnut again... - How do you discover that the secure side has graced you with a Group-1 SGI (no, you can't use one of the first 8)? for both DT and ACPI? - How do you find which CPUs are targeted by this SGI? All? One? A subset? What is the expected behaviour with CPU hotplug? How can the NS side (Linux) can inform the secure side about the CPUs it wants to use? - Is there any case where you would instead need a level interrupt (which a SGI cannot provide)? In general, cross world SGIs are a really bad idea. Yes, some people like them. I still think they are misguided, and I don't intend to provide a generic request interface for this. M. -- Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Sumit Garg <sumit.garg@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>, Devicetree List <devicetree@vger.kernel.org>, Linux Doc Mailing List <linux-doc@vger.kernel.org>, Jerome Forissier <jerome@forissier.org>, Etienne Carriere <etienne.carriere@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, Rob Herring <robh+dt@kernel.org>, Jonathan Corbet <corbet@lwn.net>, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH v2 0/7] Asynchronous notifications from secure world Date: Tue, 06 Jul 2021 11:36:17 +0100 [thread overview] Message-ID: <87czrv91b2.wl-maz@kernel.org> (raw) In-Reply-To: <CAFA6WYMSAM2MDOXnhjuZFov3BtF8-nihZRUpR8ciUWsL4_nCWA@mail.gmail.com> On Tue, 06 Jul 2021 08:25:26 +0100, Sumit Garg <sumit.garg@linaro.org> wrote: > > On Thu, 17 Jun 2021 at 11:40, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > Hi Sumit, > > > > On Thu, Jun 17, 2021 at 6:33 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Hi Jens, > > > > > > On Wed, 16 Jun 2021 at 16:07, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > > > > > Hi all, > > > > > > > > This adds support for asynchronous notifications from OP-TEE in secure > > > > world to the OP-TEE driver. This allows a design with a top half and bottom > > > > half type of driver where the top half runs in secure interrupt context and > > > > a notifications tells normal world to schedule a yielding call to do the > > > > bottom half processing. > > > > > > > > An interrupt is used to notify the driver that there are asynchronous > > > > notifications pending. > > > > > > > > > > It looks like a nice feature. I would like to get hands on with this. > > > Can I test this feature on Qemu? > > > > Absolutely, you can get this into the normal OP-TEE development repo setup with: > > repo init -u https://github.com/OP-TEE/manifest.git -m default.xml > > repo sync > > Update optee_os with > > https://github.com/jenswi-linaro/optee_os/tree/async_notif_v2 > > Update linux with https://github.com/jenswi-linaro/linux-1/tree/async_notif_v2 > > cd build > > make all -j... > > make run-only > > > > If you type anything at the secure console you'll notice how it > > changes behaviour once the Linux kernel has booted. > > > > Thanks for sharing instructions as I now got some time to test and > deep dive into this feature. It looks like a pretty useful feature to > realize interrupt support in the secure world in its true sense. This > feature works for me as per your instructions. > > I could recognise it's requirement from the time while I was playing > with secure timer interrupt support for OP-TEE RNG driver on > Developerbox. In that case I had to strip down the secure interrupt > handler to a minimum that would just collect entropy and dump into the > secure buffer. But with asynchronous notifications support, I could > add more functionality like entropy health tests in the bottom half > instead of doing those health tests while retrieving entropy from the > secure world. > > Given that, have you explored the possibility to leverage SGI rather > than a platform specific SPI for notifying the normal world? If it's > possible to leverage Architecture specific SGI for this purpose then I What does "Architecture specific SGI" mean? > think this feature will come automatically enabled for every platform > without the need to reserve a platform specific SPI. That old chestnut again... - How do you discover that the secure side has graced you with a Group-1 SGI (no, you can't use one of the first 8)? for both DT and ACPI? - How do you find which CPUs are targeted by this SGI? All? One? A subset? What is the expected behaviour with CPU hotplug? How can the NS side (Linux) can inform the secure side about the CPUs it wants to use? - Is there any case where you would instead need a level interrupt (which a SGI cannot provide)? In general, cross world SGIs are a really bad idea. Yes, some people like them. I still think they are misguided, and I don't intend to provide a generic request interface for this. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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:[~2021-07-06 10:36 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-16 10:36 [PATCH v2 0/7] Asynchronous notifications from secure world Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 1/7] docs: staging/tee.rst: add a section on OP-TEE notifications Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 2/7] dt-bindings: arm: Convert optee binding to json-schema Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 16:03 ` Rob Herring 2021-06-16 16:03 ` Rob Herring 2021-06-16 16:05 ` Rob Herring 2021-06-16 16:05 ` Rob Herring 2021-06-22 8:38 ` Jens Wiklander 2021-06-22 8:38 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 3/7] dt-bindings: arm: optee: add interrupt property Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 16:05 ` Rob Herring 2021-06-16 16:05 ` Rob Herring 2021-06-22 8:41 ` Jens Wiklander 2021-06-22 8:41 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 4/7] tee: fix put order in teedev_close_context() Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 5/7] tee: add tee_dev_open_helper() primitive Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 6/7] optee: separate notification functions Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 10:36 ` [PATCH v2 7/7] optee: add asynchronous notifications Jens Wiklander 2021-06-16 10:36 ` Jens Wiklander 2021-06-16 14:08 ` Ard Biesheuvel 2021-06-16 14:08 ` Ard Biesheuvel 2021-06-17 4:33 ` [PATCH v2 0/7] Asynchronous notifications from secure world Sumit Garg 2021-06-17 4:33 ` Sumit Garg 2021-06-17 6:10 ` Jens Wiklander 2021-06-17 6:10 ` Jens Wiklander 2021-07-06 7:25 ` Sumit Garg 2021-07-06 7:25 ` Sumit Garg 2021-07-06 10:36 ` Marc Zyngier [this message] 2021-07-06 10:36 ` Marc Zyngier 2021-07-06 11:39 ` Sumit Garg 2021-07-06 11:39 ` Sumit Garg 2021-07-06 12:46 ` Marc Zyngier 2021-07-06 12:46 ` Marc Zyngier 2021-07-07 5:52 ` Sumit Garg 2021-07-07 5:52 ` Sumit Garg 2021-07-07 6:54 ` Jens Wiklander 2021-07-07 6:54 ` Jens Wiklander 2021-07-07 17:51 ` Sudeep Holla 2021-07-07 17:51 ` Sudeep Holla 2021-07-08 12:56 ` Sumit Garg 2021-07-08 12:56 ` Sumit Garg 2021-07-09 8:05 Etienne CARRIERE 2021-07-13 11:11 ` Sudeep Holla 2021-07-13 11:11 ` Sudeep Holla 2021-07-20 6:45 ` Jens Wiklander 2021-07-20 6:45 ` Jens Wiklander 2021-07-20 7:50 ` Sudeep Holla 2021-07-20 7:50 ` Sudeep Holla 2021-07-20 9:59 ` Jens Wiklander 2021-07-20 9:59 ` Jens Wiklander
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=87czrv91b2.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=ardb@kernel.org \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=etienne.carriere@linaro.org \ --cc=jens.wiklander@linaro.org \ --cc=jerome@forissier.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=op-tee@lists.trustedfirmware.org \ --cc=robh+dt@kernel.org \ --cc=sumit.garg@linaro.org \ --cc=vincent.guittot@linaro.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.