nvidia-tegra-modules.git/include/linux/trusty/trusty.h, branch rtss22-ae NVIDIA's kernel modules to support tegra chips (used in Jetson boards) trusty: k4.14 porting 2018-08-10T13:53:39+00:00 Stephen Wolfe swolfe@nvidia.com 2018-07-24T21:11:29+00:00 b0824932575763fb0c32f7ecb372aa81c2d2a229 address K4.14 trusty driver build fixes Bug 200422831 Change-Id: I96d41f3eab3a95979a387df009adc503ec0f49c2 Signed-off-by: Stephen Wolfe <swolfe@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1787793 Reviewed-by: Mahesh Lagadapati <mlagadapati@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Sachin Nikam <snikam@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com> 
address K4.14 trusty driver build fixes

Bug 200422831

Change-Id: I96d41f3eab3a95979a387df009adc503ec0f49c2
Signed-off-by: Stephen Wolfe <swolfe@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1787793
Reviewed-by: Mahesh Lagadapati <mlagadapati@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
trusty: disable trusty irq's when trusty crashes 2018-07-27T21:12:44+00:00 Stephen Wolfe swolfe@nvidia.com 2017-10-30T02:39:44+00:00 111a90676b10d3fbb9de161775724e1194e83aa6 After trusty panics, whenever control reaches trusty will immediately context switch back to NS world. This triggers a trusty irq in the linux kernel, which eventually causes control to return back to trusty. This causes an endless loop of context switching back and forth between non-secure and secure world, and generates log spew. This commit fixes this issue by disabling trusty irq's once trusty crashes. The crash is detected in the trusty driver, who signals the trusty-irq driver to disable interrupts via a notifier chain. Bug 1883981 Change-Id: Ib7d8f921537f6aa423bd1372d8073bfa73b81fa4 Signed-off-by: Stephen Wolfe <swolfe@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1591010 (cherry picked from commit 55756bf62e988fe028791d95bc54b5345863c098) Reviewed-on: https://git-master.nvidia.com/r/1600497 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Mihir Joshi <mihirj@nvidia.com> Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com> 
After trusty panics, whenever control reaches trusty will
immediately context switch back to NS world. This triggers a trusty
irq in the linux kernel, which eventually causes control to return back
to trusty. This causes an endless loop of context switching back and
forth between non-secure and secure world, and generates log spew.

This commit fixes this issue by disabling trusty irq's once trusty
crashes. The crash is detected in the trusty driver, who signals the
trusty-irq driver to disable interrupts via a notifier chain.

Bug 1883981

Change-Id: Ib7d8f921537f6aa423bd1372d8073bfa73b81fa4
Signed-off-by: Stephen Wolfe <swolfe@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1591010
(cherry picked from commit 55756bf62e988fe028791d95bc54b5345863c098)
Reviewed-on: https://git-master.nvidia.com/r/1600497
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mihir Joshi <mihirj@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
trusty: Add return check for IPA to PA 2018-07-27T21:12:44+00:00 Anthony Zhou anzhou@nvidia.com 2016-07-04T08:31:30+00:00 da468442a086845539fd5cebcf3f831aec69cd3a Check the return value of hyp_ipa_translate, if it is not 0, report error and return. Bug 200044390 Change-Id: Ic28a18164e162d5a399b4227f42f04cc97cedbce Signed-off-by: Anthony Zhou <anzhou@nvidia.com> Reviewed-on: http://git-master/r/1241638 (cherry picked from commit 4e06cd93edec2d67c62d6fc9408e2690afbfc9fd) Reviewed-on: https://git-master.nvidia.com/r/1488435 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com> GVS: Gerrit_Virtual_Submit Tested-by: Stephen Wolfe <swolfe@nvidia.com> Reviewed-by: Timo Alho <talho@nvidia.com> 
Check the return value of hyp_ipa_translate, if it is not 0,
report error and return.

Bug 200044390

Change-Id: Ic28a18164e162d5a399b4227f42f04cc97cedbce
Signed-off-by: Anthony Zhou <anzhou@nvidia.com>
Reviewed-on: http://git-master/r/1241638
(cherry picked from commit 4e06cd93edec2d67c62d6fc9408e2690afbfc9fd)
Reviewed-on: https://git-master.nvidia.com/r/1488435
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: Stephen Wolfe <swolfe@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>
Add polling thread to poll TX vq 2018-07-27T21:12:44+00:00 Amith Nuggehalli aramachan@nvidia.com 2017-09-07T05:19:16+00:00 9b415b21b13c94f26269dfb97f648be59f931ef8 *** This change is needed for multi-guest trusty use-case only *** Trusty (TOS) splits the incoming requests into kernel and user threads. These threads are blocked on events, run when their event is released. Trusty also has an idle thread whose priority is lower than all other threads in the OS. It runs when there is no other active thread to run and it takes the cpu back to the NS world (idle return). In multi-guest configuration, TOS can receive requests from multiple guests concurrently. While some requests are exclusive rest others access shared system resources such as SE engine keyslots and so on. Infact, trusted applications can also be considered to be shared resources as they are single threaded and only one instance of each TA runs on the system. Threads waiting on shared resources or service from a server, go to sleep if the wait is not released immediately. In such cases, the incoming guest returns back to the kernel, while its requests are still waiting in TOS.This guest kernel would need some kind of a callback or an asynchronous event or rudimentary polling to inform its requests are completed. The cpu running in trusty runs all the waiting threads before it returns back to its guest. This fix checks the VQ for any new buffers at every second. So at the end of each interval, there is a guarantee that the kernel looks at its Rx queues and notifies the clients waiting on their channels for any new messages. JIRA: SEC-412 TESTS: Ran 10,000 iterations of sample_client1 calling crypto, secure storage, secure RTC and nvcrypto APIs concurrently on both guest VMs in a linux-linux configuration. Tests complete successfully. Change-Id: I7e336c79cac0ebb36a81921553243c09c98a6568 Signed-off-by: Amith Nuggehalli <aramachan@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1550450 Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Mihir Joshi <mihirj@nvidia.com> Reviewed-by: Varun Wadekar <vwadekar@nvidia.com> 
*** This change is needed for multi-guest trusty use-case only ***

Trusty (TOS) splits the incoming requests into kernel and user threads.
These threads are blocked on events, run when their event is released.
Trusty also has an idle thread whose priority is lower than all other
threads in the OS. It runs when there is no other active thread to run
and it takes the cpu back to the NS world (idle return).

In multi-guest configuration, TOS can receive requests from multiple
guests concurrently. While some requests are exclusive rest others
access shared system resources such as SE engine keyslots and so on.
Infact, trusted applications can also be considered to be shared
resources as they are single threaded and only one instance of
each TA runs on the system.

Threads waiting on shared resources or service from a server, go
to sleep if the wait is not released immediately. In such cases,
the incoming guest returns back to the kernel, while its requests
are still waiting in TOS.This guest kernel would need some
kind of a callback or an asynchronous event or rudimentary polling to
inform its requests are completed. The cpu running in trusty runs all
the waiting threads before it returns back to its guest.

This fix checks the VQ for any new buffers at every second. So
at the end of each interval, there is a guarantee that the kernel
looks at its Rx queues and notifies the clients waiting on their
channels for any new messages.

JIRA: SEC-412

TESTS: Ran 10,000 iterations of sample_client1 calling crypto, secure
       storage, secure RTC and nvcrypto APIs concurrently on both guest
       VMs in a linux-linux configuration. Tests complete successfully.

Change-Id: I7e336c79cac0ebb36a81921553243c09c98a6568
Signed-off-by: Amith Nuggehalli <aramachan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1550450
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mihir Joshi <mihirj@nvidia.com>
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
trusty/virtio_ring: use real PA instead IPA 2018-07-27T21:12:44+00:00 Amith aramachan@nvidia.com 2015-11-20T23:02:08+00:00 5d873fd2532a861ac7554f4ac348d032f3dc5d4c If hypervisor exit, trusty won't know the real PA from a guest. So call HVC get the real PA first. Bug 200044390 Change-Id: Ibca05b8465e254f4bb173e1ea1e820fb3846f922 Reviewed-on: http://git-master/r/1198267 Signed-off-by: Haley Teng <hteng@nvidia.com> (cherry picked from commit cf08ac832fcb22b000a8bbc08cb48bdf53928069) Reviewed-on: http://git-master/r/1323007 GVS: Gerrit_Virtual_Submit Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Sachin Nikam <snikam@nvidia.com> 
If hypervisor exit, trusty won't know the real PA
from a guest. So call HVC get the real PA first.

Bug 200044390

Change-Id: Ibca05b8465e254f4bb173e1ea1e820fb3846f922
Reviewed-on: http://git-master/r/1198267
Signed-off-by: Haley Teng <hteng@nvidia.com>
(cherry picked from commit cf08ac832fcb22b000a8bbc08cb48bdf53928069)
Reviewed-on: http://git-master/r/1323007
GVS: Gerrit_Virtual_Submit
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
trusty: use #if IS_ENABLED() instead of #ifdef 2018-07-27T21:12:44+00:00 Nicolin Chen nicolinc@nvidia.com 2017-03-23T22:20:17+00:00 3ff9b80495a8c901d084f811594a7999d8bd620f The CONFIG_TRUSTY could be selected as a module while should still work for trusty driver. Prior to this patch, there're compile errors when selecting CONFIG_TRUSTY=m: drivers/trusty/trusty.c:93:5: error: redefinition of 'trusty_fast_call32' drivers/trusty/trusty.c:109:5: error: redefinition of 'trusty_fast_call64' So this patch just changes the "#ifdef" to "#if IS_ENABLED". Bug 200305192 Change-Id: I867af8ce112be6eaf86c6bde311e248b1f601884 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-on: http://git-master/r/1475902 Reviewed-by: Automatic_Commit_Validation_User GVS: Gerrit_Virtual_Submit Reviewed-by: Sachin Nikam <snikam@nvidia.com> 
The CONFIG_TRUSTY could be selected as a module while should
still work for trusty driver.

Prior to this patch, there're compile errors when selecting
CONFIG_TRUSTY=m:

drivers/trusty/trusty.c:93:5: error: redefinition of 'trusty_fast_call32'
drivers/trusty/trusty.c:109:5: error: redefinition of 'trusty_fast_call64'

So this patch just changes the "#ifdef" to "#if IS_ENABLED".

Bug 200305192

Change-Id: I867af8ce112be6eaf86c6bde311e248b1f601884
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-on: http://git-master/r/1475902
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
trusty: add dt node based checks 2018-07-27T21:12:44+00:00 Nitin Kumbhar nkumbhar@nvidia.com 2016-09-23T08:51:40+00:00 44b6cc594ef9b3173261832cfa8f0063f0f3a63c Update trusty driver(s) to inclue trusty DT node based run time checks for presence of trusty device. All APIs exported to clients are updated to include this check. If trusty DT node is absent or in disabled state, these interfaces return an error. Bug 200173095 Change-Id: Ib8853c9c4b25efa3a69c3cd83e4eb6c77be42d9a Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com> Reviewed-on: http://git-master/r/1225984 (cherry picked from commit 585cb6718254db2e75b949efbf8ac76903c6ee86) 
Update trusty driver(s) to inclue trusty DT node based
run time checks for presence of trusty device. All APIs
exported to clients are updated to include this check.
If trusty DT node is absent or in disabled state, these
interfaces return an error.

Bug 200173095

Change-Id: Ib8853c9c4b25efa3a69c3cd83e4eb6c77be42d9a
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Reviewed-on: http://git-master/r/1225984
(cherry picked from commit 585cb6718254db2e75b949efbf8ac76903c6ee86)
trusty: add support for parameterized NOP ops 2018-07-27T21:12:44+00:00 Michael Ryleev gmar@google.com 2016-10-11T18:01:14+00:00 27e57ad67ae0b76cdf94e323c07b6db90f11bea4 Parameterized NOPs are introduced by Trusty secure side to facilitate better SMP concurrency. They are effectively NOP calls with parameters that will be routed to appropriate handlers on secure side which can be executed concurrently on multiple CPUs. Parameterized NOPs are represented by trusty_nop structure that has to be initialized by calling trusty_nop_init call. This patch creates queue for such items, adds per CPU work queue to invoke them and adds API to enqueue and dequeue them. Change-Id: I4c450c3d6cc18b246dfd0ca4526ef8703c1c2d64 Signed-off-by: Michael Ryleev <gmar@google.com> 
Parameterized NOPs are introduced by Trusty secure side to
facilitate better SMP concurrency. They are effectively NOP
calls with parameters that will be routed to appropriate
handlers on secure side which can be executed concurrently
on multiple CPUs. Parameterized NOPs are represented by
trusty_nop structure that has to be initialized by calling
trusty_nop_init call. This patch creates queue for such items,
adds per CPU work queue to invoke them and adds API to enqueue
and dequeue them.

Change-Id: I4c450c3d6cc18b246dfd0ca4526ef8703c1c2d64
Signed-off-by: Michael Ryleev <gmar@google.com>
trusty: Select api version 2018-07-27T21:12:44+00:00 Arve Hjønnevåg arve@android.com 2015-06-12T02:34:28+00:00 4de081ad8ef79596293b299c05c2c0c67e8f2bf4 Select api version in probe, and store it in trusty_state. This enables new return codes from trusty, and will later be used to enable a nop stdcall that does not take smc_lock. Change-Id: Ib0c41b8b14e0638851d5236f83677c25507a2db6 Signed-off-by: Michael Ryleev <gmar@google.com> 
Select api version in probe, and store it in trusty_state.
This enables new return codes from trusty, and will later be used
to enable a nop stdcall that does not take smc_lock.

Change-Id: Ib0c41b8b14e0638851d5236f83677c25507a2db6
Signed-off-by: Michael Ryleev <gmar@google.com>
trusty: add couple non-secure memory related helper routines 2018-07-27T21:12:44+00:00 Michael Ryleev gmar@google.com 2015-03-27T02:31:25+00:00 cb7f0c33bd6733dab9f76adaaa1eeea77065054c trusty_encode_page_info - encodes page physical address, memory type and other attributes into architecture specific structure that can be parsed by secure side. trusty_call32_mem_buf - can be used by drivers to make specified smc call with physicaly contigues memory buffer as an argument. Memory buffer info in retrieved by trusty_encode_page_info and along with buffer size is encoded into series of 32-bit smc call parameters. Change-Id: Iae155c0eff0bb6269be1abbe53ee42f27a1c23f5 Signed-off-by: Michael Ryleev <gmar@google.com> 
trusty_encode_page_info - encodes page physical address, memory
type and other attributes into architecture specific structure
that can be parsed by secure side.

trusty_call32_mem_buf - can be used by drivers to make
specified smc call with physicaly contigues memory buffer as
an argument. Memory buffer info in retrieved by trusty_encode_page_info
and along with buffer size is encoded into series of 32-bit
smc call parameters.

Change-Id: Iae155c0eff0bb6269be1abbe53ee42f27a1c23f5
Signed-off-by: Michael Ryleev <gmar@google.com>