nvidia-tegra-modules.git/include/linux/trusty, branch gpu-paging 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-ipc: Fix a race condition in tipc_release 2018-07-27T21:12:44+00:00 Michael Ryleev gmar@google.com 2018-03-21T17:21:03+00:00 ee6fbe3a25ff94cf062f18dad4c78ed14f7924a1 Under certain conditions it is possible that an instance of tipc_dn_chan structure will be freed in context of tipc_release call while still be referenced and in use by corresponding instance of tipc_chan struct. In order to fix that, we will need to make sure that corresponding tipc_chan struct is not in use before freeing tipc_dn_chan struct. This CL introduces and implements a new callback in tipc_chan_ops struct, called handle_release, that when specified will be called while an instance of tipc_chan object is getting destroyed. This is only possible when the last reference to tipc_chan struct goes away so it is not in use anymore. Change-Id: I93849aab08e09374a9f8ca9fa00351839519027d Signed-off-by: Michael Ryleev <gmar@google.com> Reviewed-on: https://git-master.nvidia.com/r/1679989 Tested-by: Stephen Wolfe <swolfe@nvidia.com> Reviewed-by: Mihir Joshi <mihirj@nvidia.com> Reviewed-by: Mahesh Lagadapati <mlagadapati@nvidia.com> Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com> 
Under certain conditions it is possible that an instance of
tipc_dn_chan structure will be freed in context of tipc_release
call while still be referenced and in use by corresponding
instance of tipc_chan struct. In order to fix that, we will need
to make sure that corresponding tipc_chan struct is not in use
before freeing tipc_dn_chan struct. This CL introduces and
implements a new callback in tipc_chan_ops struct, called
handle_release, that when specified will be called while an
instance of tipc_chan object is getting destroyed. This is
only possible when the last reference to tipc_chan struct
goes away so it is not in use anymore.

Change-Id: I93849aab08e09374a9f8ca9fa00351839519027d
Signed-off-by: Michael Ryleev <gmar@google.com>
Reviewed-on: https://git-master.nvidia.com/r/1679989
Tested-by: Stephen Wolfe <swolfe@nvidia.com>
Reviewed-by: Mihir Joshi <mihirj@nvidia.com>
Reviewed-by: Mahesh Lagadapati <mlagadapati@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bharat Nihalani <bnihalani@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: smc_entity_guest_reset smc for hypervisor 2018-07-27T21:12:44+00:00 Steven Kao skao@nvidia.com 2016-03-18T06:17:16+00:00 af5f3aec798ad724697053b9e993fc53eefbfadd This smc is called by the hypervisor before hypervisor guest reset. VFND-1273 Bug 200145347 Change-Id: I9f599943768038c50e87e5f2b299d06099ee8a36 Signed-off-by: Steven Kao <skao@nvidia.com> Reviewed-on: http://git-master/r/1114457 (cherry picked from commit c8e2d669e69541da8bfa6ad795839f30874e2fbc) Reviewed-on: http://git-master/r/1219491 (cherry picked from commit c334664e2208dee4c1e4480da76e5f2f23f202f3) Reviewed-on: https://git-master.nvidia.com/r/1538684 Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> GVS: Gerrit_Virtual_Submit 
This smc is called by the hypervisor before
hypervisor guest reset.

VFND-1273
Bug 200145347

Change-Id: I9f599943768038c50e87e5f2b299d06099ee8a36
Signed-off-by: Steven Kao <skao@nvidia.com>
Reviewed-on: http://git-master/r/1114457
(cherry picked from commit c8e2d669e69541da8bfa6ad795839f30874e2fbc)
Reviewed-on: http://git-master/r/1219491
(cherry picked from commit c334664e2208dee4c1e4480da76e5f2f23f202f3)
Reviewed-on: https://git-master.nvidia.com/r/1538684
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
GVS: Gerrit_Virtual_Submit
Add support to probe if TA is available 2018-07-27T21:12:44+00:00 Tao Ye tye@nvidia.com 2017-07-15T23:30:35+00:00 ec1519dd0198a24b3ffdcb207a6dae039af2d2f6 When connecting to Trusty via TIPC, linux kernel wants to know if the connection failure is caused by port_not_found issues such as the requested TA is not available. Bug 1896070 Jira APTS-731 Change-Id: I7fe9b895b79ba5fa82b15d2bfd90b1297fd7d017 Signed-off-by: Tao Ye <tye@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1523288 Reviewed-by: Varun Wadekar <vwadekar@nvidia.com> Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com> Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Mitch Luban <mluban@nvidia.com> Tested-by: Mrutyunjay Sawant <msawant@nvidia.com> 
When connecting to Trusty via TIPC, linux kernel wants to know
if the connection failure is caused by port_not_found issues
such as the requested TA is not available.

Bug 1896070
Jira APTS-731

Change-Id: I7fe9b895b79ba5fa82b15d2bfd90b1297fd7d017
Signed-off-by: Tao Ye <tye@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1523288
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Mitch Luban <mluban@nvidia.com>
Tested-by: Mrutyunjay Sawant <msawant@nvidia.com>
Retry NOP smc call when a guest's VIRQ is pending 2018-07-27T21:12:44+00:00 Amith Nuggehalli aramachan@nvidia.com 2017-07-26T00:17:15+00:00 02a7ce99ffe2adc39606d6e277be6593e6c9ea0c In virtualization use case, if a guest's VIRQ is pending at, the hypervisor, the control returns back control immediately to the guest without transitioning to TOS so that the guest's IRQ is handled in time. In such a case, re-try the NOP smc with the same arguments as the previous call as the SMC wouldn't have reached TOS yet. JIRA: SEC-366 Change-Id: Iff0f4fd6aab1369848736a1a7f2fa75afd3616b9 Signed-off-by: Amith Nuggehalli <aramachan@nvidia.com> (cherry picked from commit 585fea50e14410d312c9966f5520af305c56e989) Reviewed-on: https://git-master.nvidia.com/r/1533177 GVS: Gerrit_Virtual_Submit Reviewed-by: Varun Wadekar <vwadekar@nvidia.com> 
In virtualization use case, if a guest's VIRQ is pending at,
the hypervisor, the control returns back control immediately to the guest
without transitioning to TOS so that the guest's IRQ is handled
in time. In such a case, re-try the NOP smc with the same arguments
as the previous call as the SMC wouldn't have reached TOS yet.

JIRA: SEC-366

Change-Id: Iff0f4fd6aab1369848736a1a7f2fa75afd3616b9
Signed-off-by: Amith Nuggehalli <aramachan@nvidia.com>
(cherry picked from commit 585fea50e14410d312c9966f5520af305c56e989)
Reviewed-on: https://git-master.nvidia.com/r/1533177
GVS: Gerrit_Virtual_Submit
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>