Method and apparatus for processing input / output request, and electronic device

Abstract

The present application belongs to the technical field of electronic devices, and discloses a method and apparatus for processing an input / output request, and an electronic device. The method is applied to an electronic device, a first execution environment of the electronic device comprises a first working thread pool, the first working thread pool communicates, by means of a first task queue and a first result queue, with a first application running in a second execution environment of the electronic device, and the first working thread pool comprises multiple working threads used for processing input / output (IO) requests in the first task queue. The method comprises: working threads in a first working thread pool each acquire an IO request from a first task queue; for a first IO request acquired by a first working thread in the first working thread pool, the first working thread executes the first IO request, and writes an obtained first request result into a first result queue. According to the method of the present application, the efficiency of a first application in a second execution environment of an electronic device using a first execution environment to process an IO request can be improved.

Description

Method, device and electronic device for processing input and output requests

[0001] This application claims priority to Chinese patent application number 202311574759.6, filed on November 22, 2023, and entitled “Method, device and electronic device for processing input and output requests,” the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the technical field of electronic devices, and in particular to a method and device for processing input and output requests, and an electronic device. Background Art

[0003] With the development and application of internet technologies, user data faces increasing security threats (such as cyberattacks). To address this, current electronic devices generally support running a trusted execution environment (TEE). By loading and processing important data in a TEE, the security of user data in its initial state is guaranteed, as is the runtime security of legitimate applications that operate on important data.

[0004] Among them, TEE is an execution environment isolated from a rich execution environment (REE) in an electronic device. REE, also known as a normal operating environment, generally has rich functions, but generally has low security. It is usually used to run the operating system and client applications (CA) (such as social applications) of electronic devices. Compared with REE, TEE has relatively fewer functions but a high security level. It is generally used as an execution environment for operations that require confidentiality (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.). Therefore, applications running in TEE are called legitimate applications or trusted applications (TA).

[0005] Currently, in electronic devices that support both TEEs and REEs, the REEs typically directly access and use the device's input / output (IO) resources (such as disks and network cards). However, when executing IO requests, the TA in the TEE must use the REEs to execute those IO requests. Therefore, improving the efficiency of TEEs executing IO requests through the REEs has become a pressing technical challenge.

[0006] Summary of the Invention

[0007] The present application provides a method, device, and electronic device for processing input and output requests. The method provided by the present application can improve the efficiency of an application in a second execution environment of an electronic device in processing IO requests through a first execution environment.

[0008] The technical solutions provided in this application are as follows:

[0009] In the first aspect, the present application provides a method for processing input / output (IO) requests, which is applied to an electronic device, wherein the first execution environment of the electronic device includes a first work thread pool, and the first work thread pool communicates with a first application running in the second execution environment of the electronic device through a first task queue and a first result queue, the first task queue is used to store the IO request of the first application, and the first result queue is used to store the request result of the IO request, and the first work thread pool includes multiple work threads for processing IO requests in the first task queue. The method includes: the work threads in the first work thread pool respectively obtain IO requests from the first task queue; for the first IO request obtained by the first work thread in the first work thread pool from the first task queue, the first work thread executes the first IO request to obtain the first request result; the first work thread writes the first request result into the first result queue. Wherein, the first work thread is any work thread in the first work thread pool that obtains the IO request.

[0010] Through the method provided by this application, multiple worker threads of the first worker thread pool in the first execution environment of the electronic device are used to process the IO requests of the first application running in the second execution environment of the electronic device. This can improve the efficiency of the first application in the second execution environment in processing IO requests through the first execution environment. In addition, since the first execution environment and the second execution environment are running simultaneously in the electronic device, during the execution of the method provided by this application, the electronic device does not need to frequently call instructions to switch between the first execution environment and the second execution environment. This can save the resource overhead required for switching the execution environment, thereby ensuring the performance of the electronic device.

[0011] In one possible design, the first execution environment of the electronic device also includes a second working thread pool, which communicates with the second application in the second execution environment through a second task queue and a second result queue. The second task queue is used to store the IO requests of the second application, and the second result queue is used to store the request results of the IO requests of the second task queue. The second working thread pool includes multiple working threads, and the working threads in the second working thread pool are used to process the IO requests in the second task queue and to write the obtained results into the second result queue.

[0012] Through this possible design, the method provided by the present application creates corresponding worker thread pools in the first execution environment for different applications (e.g., the first application and the second application) in the second execution environment. In this way, multiple worker threads corresponding to each application in the second execution environment and located in the worker thread pool in the first execution environment can concurrently process the IO requests of each application. In other words, the present application supports concurrently processing IO requests of multiple applications in the second execution environment in the first execution environment, thereby improving the processing efficiency of processing IO requests of multiple applications in the second execution environment by the first execution environment.

[0013] In another possible design, the first execution environment of the electronic device also includes a detection thread corresponding to the first work thread pool. Before the work threads in the first work thread pool respectively obtain IO requests from the first task queue, the method also includes: the work threads in the first work thread pool that are in a dormant state receive a wake-up instruction sent by the detection thread; in response to the wake-up instruction, the work threads in the first work thread pool that are in a dormant state switch from a dormant state to a ready state. In this case, the work threads in the above-mentioned first work thread pool respectively obtain IO requests from the first task queue, including: the work threads in the first work thread pool that switch from a dormant state to a ready state respectively obtain IO requests from the first task queue. The detection thread is used to detect whether the first task queue is empty, and to determine whether there are dormant work threads in the first work thread pool when it is detected that the first task queue is not empty, and to send a wake-up instruction to the dormant work threads in the first work thread pool when it is determined that there are dormant work threads in the first work thread pool.

[0014] This possible design indicates that the working thread for processing IO requests in the first execution environment is in a dormant state when not executing an IO request, thereby achieving the purpose of saving resources in the electronic device when the working thread is idle.

[0015] In another possible design, when no worker threads are in a dormant state in the first worker thread pool, the detection thread is further configured to create a first preset number of worker threads in the first worker thread pool. In this case, the worker threads in the first worker thread pool respectively obtain IO requests from the first task queue, including: the newly created worker threads in the first worker thread pool respectively obtain IO requests from the first task queue.

[0016] Through this possible design, when the number of IO requests of the first application in the second execution environment is large, a new working thread is created in the first execution environment in a timely manner, thereby improving the processing efficiency of the IO requests of the first application in the second execution environment.

[0017] In another possible design, when the above-mentioned detection thread is used to periodically detect whether the first task queue is empty, the detection thread is also used to detect the frequency of writing IO requests to the first task queue in each cycle to obtain a detection result for each cycle, and the detection result is used to adjust the cycle duration of the detection thread to detect whether the first task queue is empty.

[0018] By this possible design, can realize in time according to the frequency that writes IO request to the first task queue, regulating and detecting whether the first task queue is empty cycle duration.For example, when the frequency that writes IO request to the first task queue is higher, shorten and detect whether the first task queue is empty cycle duration.For another example, when the frequency that writes IO request to the first task queue is lower, increase and detect whether the first task queue is empty cycle duration.Like this, can on the basis of the efficiency of guaranteeing to process IO request in the first task queue, also effectively save and be used to detect whether the first task queue is empty detection thread to the occupancy of electronic equipment resource.

[0019] In another possible design, the detection thread is further configured to destroy a second preset number of dormant worker threads in the first worker thread pool when detecting that the first task queue is empty.

[0020] Through this possible design, when there is no IO request in the first task queue, the redundant working threads in the first working thread pool are destroyed in time, which can effectively reduce the occupation of resources in the electronic device by the working threads.

[0021] In another possible design, after the first worker thread writes the first request result into the first result queue, or after the first worker thread writes the first request result into the first result queue and receives status information indicating that the queue is empty from the first task queue when obtaining the IO request from the first task queue again, the method further includes: the first worker thread sets its own state to a sleep state.

[0022] Through this possible design, it is possible to put idle working threads that have processed IO requests into a dormant state, which can reduce the occupation of electronic device resources by these working threads.

[0023] In another possible design, the IO request of the first application includes a disk IO request. In this case, the first task queue is used to store the disk IO request of the first application.

[0024] In another possible design, the IO request of the first application also includes a network IO request. In this case, the first execution environment of the electronic device also includes a third worker thread pool, which communicates with the first application via a third task queue and a third result queue. The third task queue is used to store the network IO requests of the first application, and the third result queue is used to store the request results of the network IO requests in the third task queue. The third worker thread pool includes multiple worker threads, and the worker threads in the third worker thread pool are used to process the network IO requests in the third task queue and write the obtained request results to the third result queue.

[0025] Through the above two possible designs, the processing efficiency of processing disk IO requests and network IO requests of applications in the second execution environment by the worker thread in the first execution environment can be improved.

[0026] In yet another possible design, the security level of the first execution environment in the electronic device is different from the security level of the second execution environment.

[0027] In another possible design, the first execution environment in the electronic device is a rich execution environment (REE), and the second execution environment is a trusted execution environment (TEE).

[0028] In the second aspect, the present application provides a method for processing IO requests, which is applied to an electronic device, wherein a first application is running in the second execution environment of the electronic device, and the first application communicates with the first execution environment of the electronic device through a first task queue and a first result queue, and the first task queue is used to store the IO requests of the first application, and the first result queue is used to store the request results of the IO requests in the first task queue. The method includes: the first application writes a first IO request to the first task queue; the first application obtains a first request result of the first IO request from the first result queue. The first IO request is any IO request written by the first application to the first task queue, and the first request result is the request result obtained after the working thread in the working thread pool corresponding to the first application in the first execution environment processes the first IO request.

[0029] In one possible design, a second application is also running in the second execution environment of the electronic device. The second application communicates with the first execution environment through a second task queue and a second result queue. The second task queue is used to store the IO requests of the second application, and the second result queue is used to store the request results of the IO requests in the second task queue. The request result is the request result obtained after the working thread in the working thread pool corresponding to the second application in the first execution environment processes the IO request in the second task queue.

[0030] In another possible design, the IO request of the first application includes a disk IO request. In this case, the first task queue is used to store the disk IO request of the first application.

[0031] In another possible design, the IO requests of the first application also include network IO requests. In this case, the first application further communicates with the first execution environment through a third task queue and a third result queue. The third task queue is used to store the network IO requests of the first application, and the third result queue is used to store the request results of the network IO requests in the third task queue. The request results are obtained after the worker threads in the worker thread pool corresponding to the first application in the first execution environment process the IO requests in the third task queue.

[0032] In yet another possible design, the security level of the first execution environment in the electronic device is different from the security level of the second execution environment.

[0033] In another possible design, the first execution environment in the electronic device is REE, and the second execution environment is TEE.

[0034] In another possible design, after the first application writes the first IO request to the first task queue, the method further includes: receiving a first identifier (ID) of the first IO request returned by the first task queue. In this case, the first application obtains the first request result of the first IO request from the first result queue, including: determining the request result including the first ID among the request results obtained from the first result queue as the first request result. Each request result in the first result queue includes the ID of the IO request that obtained each request result.

[0035] It should be understood that the description of the beneficial effects of any method provided in the second aspect can refer to the description of the beneficial effects of the corresponding method provided in the first aspect, and no further details will be given.

[0036] In a third aspect, the present application provides a device for processing IO requests.

[0037] In one possible design, the processing device is used to execute any one of the methods provided in the first aspect above. The present application may divide the processing device into functional modules according to any one of the methods provided in the first aspect above. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. Exemplarily, the present application may divide the processing device into an acquisition unit, an execution unit, and a writing unit, etc. according to the function. The description of the possible technical solutions and beneficial effects executed by each of the divided functional modules can refer to the technical solutions provided by the first aspect or its corresponding possible design, and will not be repeated here.

[0038] In another possible design, the processing device is used to execute any of the methods provided in the second aspect above. The present application can divide the processing device into functional modules according to any of the methods provided in the second aspect above. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. Exemplarily, the present application can divide the processing device into a writing unit and an acquisition unit, etc. according to the function. The description of the possible technical solutions and beneficial effects executed by the above-mentioned divided functional modules can refer to the technical solutions provided by the second aspect or its corresponding possible design, and will not be repeated here.

[0039] In another possible design, the processing device includes: a first processing unit and a second processing unit. The first processing unit is configured to run a first execution environment and to execute any of the methods provided in any possible design of the first aspect. The second processing unit is configured to run a second execution environment and to execute any of the methods provided in any possible design of the second aspect.

[0040] In another possible design, the processing device includes: one or more processors, a memory and a communication interface, the one or more processors receive or send data through the communication interface, and the one or more processors are configured to call program instructions stored in the memory so that the processing device executes any method provided in any possible design method in the first aspect and / or the second aspect.

[0041] In a fourth aspect, the present application provides an electronic device comprising one or more processors and a memory, wherein the one or more processors are configured to read first program instructions in the memory to run a first execution environment and perform any method provided in any possible design manner in the first aspect. The one or more processors are further configured to read second program instructions in the memory to run a second execution environment and perform any method provided in any possible design manner in the second aspect.

[0042] In a fifth aspect, the present application provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium, and the computer-readable storage medium includes program instructions. When the program instructions are run on a computer or processor, the computer or processor executes the method provided in any possible implementation of the first aspect and / or the second aspect of the present application.

[0043] In a sixth aspect, the present application provides a computer program product comprising instructions, which, when the computer program product is run on a computer or a processor, enables the computer or the processor to execute the method provided in any possible implementation of the first aspect and / or the second aspect of the present application.

[0044] In the seventh aspect, the present application provides a chip, which includes a processor, in which a first execution environment and a second execution environment are running, and is used to execute the method provided in any possible implementation of the first aspect in the first execution environment, and to execute the method provided in any possible implementation of the second aspect in the second execution environment.

[0045] Exemplarily, the chip further includes an input interface, an output interface, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The memory is used to store program instructions or code for implementing the method provided in any possible implementation of the first aspect and / or the second aspect, and to store I / O requests and I / O request results.

[0046] It can be understood that any of the devices, electronic devices, computer-readable storage media, computer program products, etc. provided above can be applied to the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods and will not be repeated here.

[0047] In this application, the name of the IO request processing device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear with other names. As long as the functions of each device or functional module are similar to those of this application, they are all within the scope of protection of this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] FIG1 is a schematic diagram of a process in which a TA in a TEE executes an IO request through a REE;

[0049] FIG2 is a schematic diagram of a real-time environment of the method provided in an embodiment of the present application;

[0050] FIG3 is a schematic diagram of a software framework of an electronic device provided in an embodiment of the present application;

[0051] FIG4 is a schematic diagram of another software framework of an electronic device provided in an embodiment of the present application;

[0052] FIG5 is a schematic diagram of another software framework of an electronic device provided in an embodiment of the present application;

[0053] FIG6 is a flow chart of a method for processing an IO request according to an embodiment of the present application;

[0054] FIG7 is another flow chart of a method for processing an IO request according to an embodiment of the present application;

[0055] FIG8 is a schematic diagram of a process in which a worker thread obtains an IO request from a first task queue according to an embodiment of the present application;

[0056] FIG9 is a schematic structural diagram of an IO request processing device provided in an embodiment of the present application;

[0057] FIG10 is a schematic structural diagram of another IO request processing device provided in an embodiment of the present application;

[0058] FIG11 is a schematic structural diagram of another IO request processing device provided in an embodiment of the present application;

[0059] FIG12 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0061] To facilitate understanding, the technology and background involved in the embodiments of this application are explained below.

[0062] 1) Shared memory (SHM)

[0063] Shared memory is a very efficient way to share and transfer data between multiple running processes (or threads) and is one of the simplest forms of inter-process communication. Shared memory allows multiple processes (or threads) to access the same memory block. Specifically, multiple processes (or threads) map the physical address of the same memory block to their respective logical address spaces. This memory block is then accessible to all processes (or threads), and this memory block becomes the shared memory used to implement inter-process communication.

[0064] 2) Daemon process

[0065] A daemon is a special type of process that runs in the background to perform specific system tasks. Some daemons are started when the system boots and run continuously until the system is shut down. Other daemons are started only when needed and terminate automatically after completing their tasks.

[0066] 3) Disk input / output (IO), network IO

[0067] Disk IO refers to the operations of reading and writing data from and to disks. Network IO refers to the operations of sending and receiving data through network interfaces or communication interfaces.

[0068] 4) Client application (CA) and trusted application (TA)

[0069] CAs are upper-layer applications in rich execution environments (REEs), such as social apps and e-commerce platforms. TAs are applications within trusted execution environments (TEEs) that perform specific tasks, such as fingerprint recognition, password processing, data encryption and decryption, and security authentication. Because TEEs have a higher security level than REEs, TAs that perform computations within TEEs have a higher security level.

[0070] In one example, each TA in the TEE has one or more corresponding CAs in the REE. For example, a social application (denoted as CA 1) and an e-commerce application (denoted as CA 2) that support payment functions in the REE both need to perform payment operations, and the payment password processing (denoted as TA 1) during payment operations is generally performed in the TEE. In other words, the two CAs in the REE (CA 1 and CA 2) correspond to one TA in the TEE (TA 1).

[0071] In another example, each CA in the REE has one or more corresponding TAs in the TEE. For example, for a social application that supports payment functions in the REE (denoted as CA 1), the payment password processing (denoted as TA 1) when the social application performs payment operations is performed in the TEE, and the security authentication when the social application logs into the user account (denoted as TA 2) is also performed in the TEE. In other words, one CA (CA 1) in the REE corresponds to two TAs in the TEE (TA 1 and TA 2).

[0072] In another example, when the CA in the REE needs to perform certain specific operations / tasks (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.) through the TEE during operation, it can call a command word to instruct the TEE's operating system (OS) (referred to as the TEE OS) to create a process (or thread) in the TEE to perform the specific operation / task. This process (or thread) is the TA running in the TEE. In other words, during operation, the CA in the REE can initiate a TA in the TEE at any time to perform specific operations / tasks (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.) that require a high-security execution environment.

[0073] Currently, in electronic devices that support TEE and REE, REE generally directly accesses and uses the IO resources of the electronic device (such as hard disk, network card, etc.), while TEE cannot directly access the IO resources of the electronic device. Therefore, the TA in TEE needs to be implemented through REE when executing IO requests.

[0074] Refer to Figure 1, which shows a schematic diagram of the process by which a TA in a TEE executes an IO request through a REE. As shown in Figure 1, in an electronic device that supports TEE and REE, the REE's operating system (OS) (denoted as REE OS) creates and starts a server-side daemon process (denoted as the daemon server) during the initialization phase. The daemon server then allocates a section of memory to serve as the SHM for communication between the daemon server and the TEE.

[0075] For example, for each TA that performs specific tasks (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.) for the CA in the REE on the TEE side, the TEE OS can create a daemon process (referred to as a daemon client) as a client for each TA. For example, as shown in Figure 1, the TEE OS creates a daemon client 1 for TA 1, a daemon client 2 for TA 2, and so on. In this way, for a TA that performs a specific task for the CA, such as TA 1, when TA 1 needs to execute an IO request (the IO request is, for example, a disk IO request to read data from the local disk of the electronic device), TA 1 can write the IO request to the SHM through the daemon client 1, and switch the execution environment of the electronic device to the REE by calling the secure monitor call (smc) instruction, the supervisor call instruction (svc) instruction, etc. in the trusted firmware (ARM trusted firmware, ATF). It should be understood that the TEE and REE here are time-sharing multiplexing of the physical resources of the electronic device to run, so when a task needs to be executed in the REE, the execution environment needs to be switched to the REE.

[0076] Furthermore, the daemon server in the REE obtains the IO request from the SHM, responds to and executes the IO request, and writes the request result obtained after executing the IO request (such as the data read after executing the disk IO request) to the SHM. Then, the daemon server in the REE switches the execution environment of the electronic device to the TEE by calling instructions such as smc and svc in the ATF. In this way, TA 1 in the TEE can obtain the request result from the SHM. In this way, the purpose of the TA in the TEE executing the IO request through the REE is achieved.

[0077] However, in current technology, the daemon server in the REE is globally unique. Therefore, when multiple TAs in a TEE, or multiple threads in a single TA, write I / O requests to the SHM, the daemon server in the REE can only process these I / O requests serially, one by one. This results in low efficiency for the TA in the TEE to execute I / O requests through the REE. Furthermore, current technology involves multiple calls to the smc and svc instructions to switch between the TEE and the REE, resulting in high switching overhead and a certain impact on the performance of the electronic device.

[0078] Based on this, an embodiment of the present application provides a method for processing IO requests, in which a first execution environment and a second execution environment are running simultaneously in an electronic device. A first application is running in the second execution environment. When the first application needs to execute an IO request, the first execution environment configures a first working thread pool for the first application, and configures the first working thread pool to communicate with the first application through a first SHM. The first SHM includes a first task queue and a first result queue. The first task queue is used to store the IO requests of the first application, and the first result queue is used to store the request results of the IO requests of the first application. The first working thread pool includes multiple working threads for processing IO requests in the first task queue. In this way, the first application can write IO requests in the first task queue, and the working threads in the first working thread pool can obtain IO requests from the first task queue and process them respectively, and write the obtained request results into the first result queue. Then, the first application obtains the request result from the first result queue.

[0079] Through the method provided in the embodiment of the present application, multiple worker threads of the first worker thread pool in the first execution environment are used to process IO requests of the first application running in the second execution environment. This can improve the efficiency of the first application in the second execution environment in processing IO requests through the first execution environment. In addition, because the first execution environment and the second execution environment are running simultaneously in the electronic device, during the execution of the method provided in the embodiment of the present application, the electronic device does not need to frequently call instructions such as smc and svc to switch between the first execution environment and the second execution environment. This can save the resource overhead required for switching the execution environment, thereby ensuring the performance of the electronic device.

[0080] Optionally, the security level of the first execution environment is different from the security level of the second execution environment. The first application is used to execute a specific task of the application in the first execution environment, and the specific task is a business that needs to be processed in the second execution environment.

[0081] In some examples, the first execution environment is the REE and the second execution environment is the TEE. In this case, the first application is used to perform a specific task of any CA in the REE. This specific task generally has a high security level and therefore needs to be processed in the TEE. For example, this specific task may be fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.

[0082] Optionally, the electronic device may be any terminal device, computing platform, or service platform running both the first and second execution environments, without limitation. For example, the electronic device may be a mobile phone, tablet, laptop, in-vehicle computer, general-purpose computer, wearable device, or other terminal device running both the first and second execution environments, without limitation. For another example, the electronic device may be a cloud computing device or server running both the first and second execution environments, without limitation.

[0083] For the sake of simplicity, the embodiments of the present application are described below using an example in which the first execution environment is REE and the second execution environment is TEE.

[0084] Refer to Figure 2, which shows a real-time environment schematic diagram of the method provided in an embodiment of the present application. As shown in Figure 2, there are two execution environments running in the electronic device, namely REE and TEE. In the REE, there is at least one CA running, such as CA 1 and CA2 shown in Figure 2. In the TEE, there is at least one TA running that performs specific tasks for the CA in the REE, such as TA 1 and TA 2 shown in Figure 2. The description of specific tasks can be referred to above and will not be repeated here. It should be understood that when TA 1 and TA 2 in the TEE need to execute an IO request, the processing of the IO request can be completed by the IO request processing method provided in the embodiment of the present application.

[0085] In one example, TA 1 and / or TA 2 are trusted applications preset in the TEE, so as to be called when the CA in the REE needs to perform a specific task (such as a data encryption service with a high security level requirement).

[0086] In another example, TA 1 and / or TA 2 are modules with high security level requirements installed in the TEE when the application (APP) is installed in the electronic device. It should be understood that modules in the APP that do not require a high security level are installed in the REE of the electronic device. For example, for an e-commerce APP, the module that implements product search and browsing in the e-commerce APP is installed in the REE of the electronic device, and the module that implements user account login and product payment in the e-commerce APP is installed in the TEE of the electronic device.

[0087] In another example, TA 1 and / or TA 2 are TAs created by the CA in the electronic device REE when it needs to perform specific tasks (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc. with high security requirements). For example, for an e-commerce app, when the e-commerce CA running on the electronic device REE responds to the user's operation and needs to log in to the user account, the e-commerce CA can instruct the electronic device's TEE to create a TA for identity security authentication.

[0088] It should be understood that the above content is an illustrative description of the implementation environment of the method provided in the embodiment of the present application, and does not constitute a limitation on the implementation environment of the method. A person skilled in the art will know that as business needs change, the implementation environment can be adjusted according to application requirements, and the embodiments of the present application do not list them one by one.

[0089] The embodiment of the present application also provides an IO request processing device, which is applied to any electronic device running REE and TEE, and the device is used to execute the IO request processing method provided in the embodiment of the present application. Optionally, the device can be any electronic device running REE and TEE, or a functional module of an electronic device running REE and TEE, without limitation. The description of the electronic device can refer to the above description and will not be repeated here.

[0090] Refer to FIG3 , which shows a schematic diagram of a software framework of an electronic device provided in an embodiment of the present application.

[0091] As shown in Figure 3, the REE OS of the electronic device includes a resident scheduling thread. For any TA running in the TEE OS of the electronic device, such as the first application, in the process of the first application executing a specific task of any CA in the REE, when the first application needs to execute an IO request, the first application sends a communication request carrying the identifier (identifier, ID) of the first application to the scheduling thread in the REE OS. For example, the first application calls the command word in the notification data (notify data) through the TEE OS to send a communication request to the scheduling thread of the first application. Among them, the ID of the first application can be the process ID of the process used to implement the first application, or the thread ID of the thread used to implement the first application, but is not limited to this.

[0092] After the scheduling thread in the REE OS receives the communication request, in response, the scheduling thread creates a first working thread pool including a preset number of working threads for the first application in the REE, applies for a section of memory of the electronic device (referred to as the first memory), and creates a first task queue and a first result queue on the first memory. The first task queue is used to store the IO requests of the first application. The working threads in the first working thread pool are used to process the IO requests in the first task queue and write the obtained request results to the first result queue. That is, the first result queue is used to store the request results of the IO requests in the first task queue. The embodiment of the present application does not specifically limit the value of the aforementioned preset number, nor does it specifically limit the specific structure of the first task queue and / or the first result queue. For example, the first task queue and / or the first result queue can be a linear queue, a circular queue, etc., and are not limited thereto. In addition, when creating the first task queue and the first result queue on the first memory, the embodiment of the present application does not limit the specific ratio of the storage space corresponding to the first task queue and the storage space corresponding to the first result queue in the first memory. For example, when the scheduling thread creates the first task queue and the first result queue in the first memory, half of the storage space of the first memory is used as the storage space corresponding to the first task queue, and the other half of the storage space of the first memory is used as the storage space of the first result queue, but is not limited thereto.

[0093] Then, the scheduling thread sends the address of the first memory in which the first task queue and the first task queue are created to each working thread and the first application in the first working thread pool. In response, the working threads and the first application in the first working thread pool receive the address of the first memory. In this way, the first memory in which the first task queue and the first result queue are created can be used as the SHM for the first working thread pool and the first application to communicate, and is recorded as the first SHM. In this way, the address of the first memory in which the first task queue and the first result queue are created is the address of the first SHM. As an example, the scheduling thread can send the address of the first memory to each thread in the first working thread pool by calling the POSIX thread standard library (posix threads, pthread) function. Wherein, POSIX refers to the portable operating system interface (portable operating system interface). As another example, the scheduling thread can send the address of the first memory to the first application based on the ID of the first application and by calling the command word in the notify data through the REE OS.

[0094] In some embodiments, the scheduling thread in the REE OS also creates a corresponding first detection thread (corresponding to the detection thread in this application) for the first SHM in the REE, and the first detection thread is used to detect the status of the first task queue and the status of the first result queue in the first SHM. For example, the first detection thread is used to detect whether the first task queue in the first SHM is empty, and to detect whether the first result queue in the first SHM is not full. In some examples, the first detection thread includes a first thread and a second thread, wherein the first thread is used to detect whether the first task queue in the first SHM is empty, and the second thread is used to detect whether the first result queue in the first SHM is not full. Among them, the detailed description of the first detection thread detecting the status of the first task queue and the status of the first result queue can be referred to the description in the method below and will not be repeated here.

[0095] In other embodiments, after the first application sends a communication request carrying the ID of the first application to the scheduling thread in the REE OS, it also creates a second detection thread in the TEE. And after receiving the address of the first SHM (i.e., the first memory), the first application sends the address of the first SHM to the second detection thread. In response, the second detection thread receives the address of the first SHM. Furthermore, the second detection thread can be used to detect the status of the first task queue and the status of the first result queue in the first SHM. For example, the second detection thread is used to detect whether the first task queue in the first SHM is not full, and to detect whether the first result queue in the first SHM is not empty. In some examples, the second detection thread includes a third thread and a fourth thread, wherein the third thread is used to detect whether the first task queue in the first SHM is not full, and the fourth thread is used to detect whether the first result queue in the first SHM is not empty. Among them, the detailed description of the second detection thread detecting the status of the first task queue and the status of the first result queue can be referred to the description in the method below and will not be repeated here.

[0096] Through the above process, the first application and the second detection thread in the TEE, as well as the first working thread pool and the first detection thread in the REE, can be associated through the first SHM. In this way, there is a corresponding relationship between the first application and the second detection thread in the TEE, and the first working thread pool and the first detection thread in the REE, which are associated through the first SHM.

[0097] In an embodiment of the present application, the SHM, and the TA and detection thread in the TEE associated through the SHM, and the working thread pool and detection thread in the REE, can be referred to as a cross-domain and cross-process trust (cross tasklet, xtasklet) framework. For example, the first SHM, and the first application and the second detection thread in the TEE associated through the first SHM, as well as the first working thread pool and the first detection thread in the REE, can be recorded as the first xtasklet framework. Applying the method provided by the embodiment of the present application in the first xtasklet framework can achieve the purpose of concurrently processing the IO requests of the first application in the TEE through the working threads in the first working thread pool in the REE, thereby improving the efficiency of processing the IO requests of the first application in the TEE. The specific process of implementing the method provided by the embodiment of the present application in the first xtasklet framework can refer to the method description below and will not be repeated here.

[0098] Continuing to refer to Figure 3, similarly, for any other TA running in the TEE OS of the electronic device, such as the second application, the embodiment of the present application can apply for a second SHM for the second application in the electronic device, create a second working thread pool and a third detection thread in the REE, and create a fourth detection thread in the TEE when the second application needs to execute an IO request, and associate the second application and the fourth detection thread in the TEE, and the second working thread pool and the third detection thread in the REE through the second SHM, thereby obtaining a second xtasklet framework. In this way, there is a corresponding relationship between the second application and the fourth detection thread in the TEE, and the second working thread pool and the third detection thread in the REE associated through the second SHM. Among them, the second SHM includes a second task queue and a second result queue. The second task queue is used to store the IO requests of the second application. The second working thread pool includes multiple working threads, which are used to process the IO requests in the second task queue and write the obtained request results into the second result queue. That is, the second result queue is used to store the request results of the IO requests of the second application.

[0099] It should be understood that by applying the method provided by the embodiment of the present application in the second xtasklet framework, it is possible to achieve the purpose of concurrently processing the IO requests of the second application in the TEE through the worker threads in the second worker thread pool in the REE, thereby improving the efficiency of processing the IO requests of the second application in the TEE. It can also be seen that the embodiment of the present application can create corresponding xtasklet frameworks for different TAs in the TEE, and by applying the method provided by the embodiment of the present application in the xtasklet framework corresponding to each TA, the efficiency of each TA in processing its own IO requests can be improved. In other words, the embodiment of the present application supports concurrent processing of the IO requests of each TA in the TEE in the REE, so that the method provided by the embodiment of the present application improves the processing efficiency of processing the IO requests of the TA in the TEE through the REE.

[0100] It should also be understood that the detailed description of creating the second working thread pool and the second working thread pool can refer to the relevant description of the first working thread pool above, the detailed description of creating the third detection thread and the third detection thread can refer to the relevant description of the first detection thread above, the detailed description of creating the fourth detection thread and the fourth detection thread can refer to the relevant description of the second detection thread above, and the detailed description of applying for the second SHM and associating the second application and the fourth detection thread in the TEE, and the second working thread pool and the third detection thread in the REE through the second SHM can refer to the above description of applying for the first SHM and associating the first application and the second detection thread in the TEE, and the first working thread pool and the first detection thread in the REE through the first SHM, and will not be repeated here.

[0101] Referring to Figure 4, Figure 4 shows another schematic diagram of the software framework of the electronic device provided by an embodiment of the present application. In conjunction with Figure 3, as shown in Figure 4, when the IO request of the first application includes a disk IO request, the first task queue described above is used to store the disk IO request of the first application. The worker threads in the first worker thread pool are used to process the disk IO requests in the first task queue and write the obtained request results to the first result queue. In other words, the first result queue is used to store the request results of the disk IO requests of the first application.

[0102] As shown in Figure 4, when the IO request of the first application also includes a network IO request, a third SHM can be applied for the first application in the electronic device, a third working thread pool and a fifth detection thread can be created in the REE, and a sixth detection thread can be created in the TEE. The first application and the sixth detection thread in the TEE, as well as the third working thread pool and the fifth detection thread in the REE are associated through the third SHM, thereby obtaining a third xtasklet framework. In this way, the first application and the sixth detection thread in the TEE, and the third working thread pool and the fifth detection thread bracket in the REE associated through the third SHM have a corresponding relationship. Among them, the third SHM includes a third task queue and a third result queue. The third task queue is used to store the network IO request of the first application. The third working thread pool includes multiple working threads, which are used to process the network IO requests in the third task queue and write the obtained request results into the third result queue. That is, the third result queue is used to store the request results of the network IO request of the first application.

[0103] It should be understood that the application of the method provided by the embodiment of the present application in the third xtasklet framework can improve the efficiency of processing the network IO requests of the first application. It should also be understood that the creation of the third working thread pool and the detailed description of the third working thread pool can refer to the relevant description of the first working thread pool above, the creation of the fifth detection thread and the fifth detection thread can refer to the relevant description of the first detection thread above, the creation of the sixth detection thread and the sixth detection thread can refer to the relevant description of the second detection thread above, and the application of the third SHM and the association of the first application and the sixth detection thread in the TEE, and the third working thread pool and the fifth detection thread in the REE through the third SHM can refer to the above application of the first SHM and the association of the first application and the second detection thread in the TEE, and the first working thread pool and the first detection thread in the REE. The description will not be repeated.

[0104] It should also be understood that for the second application shown in Figure 3, when the IO requests of the second application include disk IO requests and network IO requests, then similar to Figure 4, the embodiment of the present application can create two xtasklet frameworks for the second application. These two xtasklet frameworks include the second xtasklet framework described in Figure 3 and another xtasklet framework (recorded as the fourth xtasklet frame).

[0105] Among them, the second task queue in the second xtasklet framework is used to store the disk IO requests of the second application. The working threads in the second working thread pool in the second xtasklet framework are used to process the disk IO requests in the second task queue and write the obtained request results into the second result queue. That is, the second result queue in the second xtasklet framework is used to store the request results of the disk IO requests of the second application. In this way, applying the method provided in the embodiment of the present application in the second xtasklet framework can improve the efficiency of processing the disk IO requests of the second application in the TEE through REE.

[0106] The fourth xtasklet framework includes a fourth SHM and a fourth worker thread pool in the REE. The fourth SHM includes a fourth task queue and a fourth result queue, and the fourth task queue is used to store the network IO requests of the second application. The fourth worker thread pool includes multiple worker threads, which are used to process the network IO requests in the fourth task queue and write the obtained request results to the fourth result queue. That is, the fourth result queue is used to store the request results of the network IO requests of the second application. In this way, applying the method provided in the embodiment of the present application in the fourth xtasklet framework can improve the efficiency of processing the network IO requests of the second application in the TEE through the REE.

[0107] It can be understood that by establishing xtasklet frameworks for different types of IO requests of each TA in the TEE, the processing efficiency of processing different types of IO requests of the TA in the TEE through REE can be achieved.

[0108] Referring to Figure 5, Figure 5 shows another software framework schematic diagram of an electronic device provided by an embodiment of the present application. In combination with Figures 3 and / or 4, when the first application shown in Figures 3 and / or 4 creates a sub-application according to business needs when processing business, such as the first sub-application shown in Figure 5. As shown in Figure 5, the embodiment of the present application can apply for a fifth SHM in the electronic device for the first sub-application when it needs to execute an IO request in the process of the first sub-application processing business, create a fifth working thread pool and a seventh detection thread in the REE, and create an eighth detection thread in the TEE, and associate the first sub-application and the eighth detection thread in the TEE, and the fifth working thread pool and the seventh detection thread in the REE through the fourth SHM, thereby obtaining the fifth xtasklet framework. In this way, there is a corresponding relationship between the first sub-application and the eighth detection thread in the TEE, and the fifth working thread pool and the seventh detection thread in the REE, which are associated through the fourth SHM. Among them, the fifth SHM includes a fifth task queue and a fifth result queue. The fifth task queue is used to store the IO requests of the first sub-application. The fifth worker thread pool includes multiple worker threads, which are used to process IO requests in the fifth task queue and write the obtained request results into the fifth result queue. That is, the fifth result queue is used to store the request results of the IO requests of the first sub-application.

[0109] It should be understood that the application of the method provided by the embodiment of the present application in the fifth xtasklet framework can improve the efficiency of processing the IO requests of the first sub-application of the first application in the TEE through the REE. It should also be understood that the creation of the fifth working thread pool and the detailed description of the fifth working thread pool can refer to the relevant description of the first working thread pool above, the creation of the seventh detection thread and the seventh detection thread can refer to the relevant description of the first detection thread above, the creation of the eighth detection thread and the eighth detection thread can refer to the relevant description of the second detection thread above, and the application of the fifth SHM and the association of the first sub-application and the eighth detection thread in the TEE through the fifth SHM, as well as the fifth working thread pool and the seventh detection thread in the REE, can refer to the above application of the first SHM and the association of the first application and the second detection thread in the TEE through the first SHM, the first working thread pool and the first detection thread in the REE, and no further details will be given.

[0110] It can be understood that through the software framework provided in the embodiment of the present application, the above-mentioned xtasklet framework can be established for each sub-application of any TA in the TEE of the electronic device, so that the IO requests of each sub-application of any TA in the TEE can be processed concurrently in the REE, thereby improving the processing efficiency of the IO requests of each sub-application.

[0111] It should also be understood that after the TA in the TEE completes a specific task for the CA in the REE, the electronic device can delete or destroy the xtasklet framework created for the TA. Taking the first application in Figure 3, Figure 4, or Figure 5 as an example, after the first application in the TEE completes a specific task for the CA in the REE, it deletes the detection thread used to detect the task queue status and result queue status corresponding to the first application and automatically exits or destroys it. When the TEE OS detects that the first application has exited / destroyed, it sends a destroy instruction carrying the first application ID to the scheduling thread in the REE (such as the TEE OS sends a destroy instruction to the scheduling thread in the REE by calling the command word in the notify data) to instruct the scheduling thread in the REE to destroy / delete the detection thread and work thread pool created for the first application, and release the SHM applied for the first application. In response, after receiving the destroy instruction carrying the first application ID, the scheduling thread in the REE responds to the destroy instruction and deletes or destroys the detection thread and work thread pool created for the first application, and releases the SHM applied for the first application. In this way, the corresponding resources of the electronic device can be released in a timely manner after the first application completes the specific task.

[0112] It should be understood that the above content is an illustrative description of the software framework of the method provided in the embodiment of the present application and does not constitute a limitation on the software framework of the method. A person skilled in the art will know that as business needs change, the software framework can be adjusted according to application requirements, and the embodiments of the present application do not list them one by one.

[0113] The following describes the implementation process of the method provided in the embodiment of the present application.

[0114] Referring to FIG. 6 , FIG. 6 shows a flow chart of a method for processing an IO request provided in an embodiment of the present application. The method can be applied to the software framework shown in FIG. 3 , FIG. 4 or FIG. 5 .

[0115] For simplicity, the following describes the method provided in the embodiments of this application, assuming that the TA used to perform a specific task for the CA in the electronic device REE is the first application in the TEE shown in Figures 3, 4, or 5, and that the electronic device has established a first xtasklet framework for the first application as described above. As shown in Figure 6, the method includes the following steps.

[0116] Step 101: A first application writes an IO request to a first task queue.

[0117] When the first application in the electronic device TEE is performing a specific task for the CA in the REE (see the above description), when an IO request needs to be executed, the first application writes the IO request to be executed to the first task queue. The first application communicates with the REE of the electronic device through the first task queue and the first result queue in the first SHM. The first task queue is used to store the IO requests of the first application, and the first result queue is used to store the request results of the IO requests in the first task queue.

[0118] 4 , when the IO request of the first application includes a disk IO request, the first application writes the disk IO request to the first task queue. When the IO request of the first application also includes a network IO request, the first application writes the network IO request to the third task queue.

[0119] Taking any IO request that the first application needs to execute as a disk IO request (referred to as the first IO request) as an example, in one case, during the process of the first application writing the first IO request to the first task queue, when the first task queue is not full and the storage space corresponding to the empty element in the first task queue is larger than the size of the first IO request, the first application writes the first IO request to the first task queue normally. It is understandable that the first task queue includes multiple elements, each of which can correspond to storage space of the same size or different sizes, which is not described in detail in the embodiments of the present application.

[0120] In another case, during the process of the first application writing the first IO request to the first task queue, when the first task queue is full, after the first application executes the operation of writing the first IO request to the first task queue, the first task queue returns status information indicating that the first task queue is full to the first application. In one possible implementation, the first application responds to the status information indicating that the first task queue is full and re-executes the operation of writing the first IO request to the first task queue after a preset time length. The embodiment of the present application does not specifically limit the value of the preset time length. In another possible implementation, the first application responds to the status information indicating that the first task queue is full and sends a first indication to the second detection thread to instruct the second detection thread to continuously or periodically detect whether the first task queue is not full. Optionally, the first indication includes the size of the IO request that the first application needs to write to the first task queue. Furthermore, when the second detection thread detects that the first task queue is not full and the storage space corresponding to the empty element in the first task queue is larger than the size of the IO request that the first application needs to write to the first task queue, it sends a second indication to the first application to instruct the first application to continue writing IO requests to the first task queue. Here, the IO requests that the first application needs to write into the first task queue include but are not limited to the first IO request. It should be understood that by having the second detection thread detect whether the first task queue is not full when the first task queue is full, and notifying the first application to continue writing IO requests to the first task queue when it is detected that the first task queue is not full, the process / thread in the first application used to execute the writing of IO requests to the first task queue can process other tasks during the process of the second detection detecting whether the first task queue is not full, without having to suspend and wait, thereby improving the working efficiency of the process / thread in the first application.

[0121] Exemplary, the second detection thread can detect whether the first task queue is not full according to the position of the head pointer and the tail pointer in the first task queue. For example, when the first task queue is a linear queue, if the difference between the head pointer and the tail pointer of the first task queue is equal to the maximum length of the first task queue, it means that the first task queue is full. If the difference between the head pointer and the tail pointer of the first task queue is less than the maximum length of the first task queue, it means that the first task queue is not full, and the element between the maximum length and the tail pointer in the first task queue is an empty element in the first task queue. For another example, when the first task queue is a circular queue, if the difference between the head pointer and the tail pointer of the first task queue is equal to the maximum length of the first task queue, it means that the first task queue is full. If the difference between the head pointer and the tail pointer of the first task queue is not equal to the maximum length of the first task queue, it means that the first task queue is not full, and the element between the head pointer and the tail pointer in the reverse direction of the first task queue is an empty element in the first task queue. The reverse direction of the first task queue refers to the direction opposite to the direction of the head pointer during the process of writing data to the first task queue, or the reverse direction of the first task queue refers to the direction opposite to the direction of the tail pointer during the process of consuming data in the first task queue. Furthermore, based on the size of the storage space corresponding to each empty element in the first task queue, the second detection thread can determine whether the size of the storage space corresponding to the empty element in the first task queue is greater than the size of the IO request that the first application needs to write to the first task queue, and then determine whether it is necessary to send a second instruction to the first application to instruct the first application to continue writing IO requests to the first task queue.

[0122] Step 102: The worker threads in the first worker thread pool respectively obtain IO requests from the first task queue.

[0123] On the REE side of the electronic device, based on the position pointed to by the head pointer of the first task queue, the worker threads in the first worker thread pool respectively read the IO requests from the first task queue to obtain the IO requests from the first task queue.

[0124] In one possible implementation, the worker threads in the first worker thread pool are configured to be in a ready state. In this case, when the first task queue is not empty, the worker threads in the first worker thread pool read IO requests from the first task queue normally. When the first task queue is empty, after the worker threads in the first worker thread pool execute the operation of reading IO requests from the first task queue, the first task queue returns status information indicating that the first task queue is empty to the worker threads that read the IO requests. In response to the status information, the worker threads that read the IO requests read the IO requests from the first task queue again after a preset time length. The embodiment of the present application does not specifically limit the value of the preset time length.

[0125] In another possible implementation, the worker threads in the first worker thread pool are configured to enter a dormant state when not obtaining IO requests from the first task queue and processing IO requests. That is, the worker threads in the first worker thread pool will enter a dormant state when idle, which can save the occupation of electronic device resources (such as CPU resources, memory resources, etc.). In this case, the scheduling thread in the electronic device REE starts the first detection thread after creating the first xtasklet framework. Then the first detection thread detects whether the first task queue is empty, and instructs the worker threads in the first worker thread pool to obtain IO requests from the first task queue based on the detection result. The detailed process is described in steps 201 to 205 below and will not be repeated here.

[0126] Step 103: For the first IO request obtained by the first worker thread in the first worker thread pool from the first task queue, the first worker thread executes the first IO request and obtains a first request result.

[0127] Among them, the first working thread is any working thread in the first working thread pool corresponding to the first application that obtains the IO request, the first IO request is the IO request read by the first working thread, and the first request result is the request result obtained after the first working thread executes the first IO request.

[0128] Optionally, the first IO request may be executed by a worker thread. In this case, the first worker thread executes the first IO request after obtaining the first IO request.

[0129] As an example, when the first IO request is a disk IO request to write data to a disk (such as a hard disk) of an electronic device, the first worker thread executes an operation of writing data to the disk of the electronic device. In this case, the first request result can be a message indicating whether the data is written successfully or failed.

[0130] As another example, when the first IO request is a disk IO request to read data from a disk (such as a hard disk) of the electronic device, the first worker thread performs an operation to read data from the disk of the electronic device. In this case, the first request result is the data read from the disk of the electronic device.

[0131] As another example, when the first IO request is a network IO request to send data to a remote device, the first worker thread sends the data to be sent to the communication interface / network interface of the electronic device to implement data transmission through the communication interface / network interface of the electronic device. In this case, the first request result can be a response message received by the communication interface / network interface of the electronic device after sending the data, or a message indicating whether the communication interface / network interface of the electronic device successfully sent the data or failed to send the data, without limitation.

[0132] Optionally, when the first IO request includes a large number of IO subtasks, the first IO request may be executed by multiple worker threads. In this case, upon receiving the first IO request and executing the first IO request, the first worker thread may call at least one idle worker thread in the first worker thread pool to execute the subtasks of the first IO request, or create a new worker thread in the first worker thread pool to execute the subtasks of the first IO request, to obtain the request result of the first IO request. This is not limited to this.

[0133] Step 104: The first working thread writes the first request result into the first result queue.

[0134] After obtaining the first request result, the first working thread writes the first request result into the first result queue.

[0135] Optionally, in conjunction with Figure 4 , when the first IO request is a disk IO request, the first worker thread writes the first request result to a first result queue for storing request results of disk IO requests. When the first IO request is a network IO request, the first worker thread writes the first request result to a third result queue for storing request results of network IO requests.

[0136] Taking the example of a first worker thread writing a first request result to a first result queue, in one scenario, when the first worker thread is writing the first request result to the first result queue, if the first result queue is not full and the storage space corresponding to the empty element in the first result queue is larger than the size of the first request result, the first worker thread writes the first result request to the first result queue normally. It should be understood that the first result queue includes multiple elements, each of which can correspond to storage space of the same or different sizes, and this embodiment of the application does not describe this in detail.

[0137] In another scenario, during the process of the first working thread writing the first request result to the first result queue, when the first result queue is full, after the first working process executes the operation of writing the first request result to the first result queue, the first result queue returns status information indicating that the first result queue is full to the first working thread. In one possible implementation, the first working thread responds to the status information indicating that the first result queue is full and re-executes the operation of writing the first request result to the first result queue after a preset time length. The embodiment of the present application does not specifically limit the value of this preset time length. In another possible implementation, the first working thread responds to the status information indicating that the first result queue is full and sends a third indication to the detection thread to instruct the detection thread to continuously or periodically check whether the first result queue is not full. Optionally, the third indication includes the size of the first request result. Furthermore, when the detection thread detects that the first result queue is not full and the storage space corresponding to the empty elements in the first result queue is larger than the size of the first request result, it sends a fourth indication to the first working process to instruct the first working process to re-write the first request result to the first result queue. For detailed description of how the detection thread detects whether the first result queue is not full, please refer to the description of how the second detection thread detects whether the first task queue is not full in step 101, which will not be repeated here.

[0138] It should be understood that when the first detection thread periodically detects whether the first task queue is empty in step 102, the detection thread used to periodically detect whether the first result queue is not full in step 104 may also be the first detection thread. In this case, the detection period for periodically detecting whether the first result queue is not full only needs to be staggered with the detection period for the first detection thread to detect the first task queue.

[0139] In some examples, the first detection thread may include a first thread and a second thread. Thus, the first thread may be used to detect whether the first task queue is empty at step 102, and the second thread may be used to detect whether the first result queue is not full at step 104.

[0140] Step 105: The first application obtains the first request result of the first IO request from the first result queue.

[0141] The process of the first application obtaining the first request result of the first IO request from the first result queue includes steps 1051 to 1053 .

[0142] Step 1051: The first application receives the first ID of the first IO request returned by the first task queue.

[0143] The ID of the IO request written into the first task queue is generated by the first task queue and returned to the first application. The ID of the IO request is used by the first application to determine the request result of the IO request from the request result obtained from the first result queue.

[0144] It is understood that after the first application writes the first IO request to the first task queue in step 101, the first task queue generates a first ID for the first IO request and returns the first ID to the first application. In response, the first application receives the first ID returned by the first task queue. Therefore, the IO request written by the first application to the first task queue includes the request ID generated by the first task queue for the IO request.

[0145] Step 1052: The first application obtains the request result from the first result queue.

[0146] On the TEE side of the electronic device, the first application reads the request result from the first result queue based on the position pointed to by the head pointer in the first result queue, so as to achieve the purpose of obtaining the request result from the first result queue.

[0147] It should be understood that when the first application corresponds to multiple xtasklet frames, the first application reads the request result from each result queue based on the position pointed to by the head pointer of the result queue in each xtasklet frame. In conjunction with Figure 4, the first application corresponds to the first xtasklet frame and the third xtasklet frame. Therefore, the first application reads the request result from the first result queue based on the position pointed to by the head pointer of the first result queue in the first xtasklet frame, and the first application reads the request result from the third result queue based on the position pointed to by the head pointer of the third result queue in the third xtasklet frame.

[0148] For simplicity of description, the following description is given by taking the example of the first working thread obtaining the first request result from the first result queue.

[0149] In one case, when the first result queue is not empty, the first application reads the request result from the first result queue normally.

[0150] In another case, when the first result queue is empty, in one possible implementation, after the first application executes the operation of reading the request result from the first result queue, the first result queue returns status information indicating that the first result queue is empty to the first application. In response to the status information, the first application reads the request result from the first result queue again after a preset time length. The embodiment of the present application does not specifically limit the value of the preset time length. In another possible implementation, the first application sends a fifth indication to the detection process in response to the status information indicating that the first result queue is empty, to instruct the detection thread to continuously or periodically detect whether the first result queue is not empty. Furthermore, the detection continuously or periodically detects whether the first result queue is not empty, and when it is detected that the first result queue is not empty, sends a sixth indication to the first application to instruct the first application to continue reading the request result from the first result queue. It should be understood that by having the detection thread detect whether the first result queue is not empty when the first result queue is empty, and notifying the first application to continue reading the request results from the first result queue when it is detected that the first result queue is not empty, the process / thread in the first application used to execute the reading of the request results from the first result queue can handle other tasks during the process of the detection thread detecting whether the first result queue is not empty, without suspending and waiting, thereby improving the working efficiency of the process / thread in the first application.

[0151] As an example, the detection thread can detect whether the first result queue is not empty based on the positions of the head pointer and the tail pointer in the first result queue. For example, if the head pointer of the first result queue is not equal to the tail pointer, it indicates that the first result queue is not empty. If the head pointer of the first task queue is equal to the tail pointer, it indicates that the first result queue is empty.

[0152] It should be understood that when the second detection thread periodically detects whether the first task queue is not full in step 101, the detection thread used to periodically detect whether the first result queue is not empty in step 1052 may also be the second detection thread. In this case, the detection period for periodically detecting whether the first result queue is not empty only needs to be staggered with the detection period for the second detection thread to detect the first task queue.

[0153] In some examples, the second detection thread may include a third thread and a fourth thread. Thus, the third thread may be used to detect whether the first task queue is not full in step 101, and the fourth thread may be used to detect whether the first result queue is not empty in step 1052.

[0154] Step 1053: The first application determines the first request result from the request results obtained from the first result queue according to the first ID of the first IO request.

[0155] When the first IO request is written into the first task queue of the first xtasklet framework, the first application determines the first request result from the request results obtained from the first result queue in the first xtasklet framework according to the first ID.

[0156] Each request result in the first result queue includes the ID of the IO request that obtained the request result. It should be understood that in step 103, after the first worker thread obtains any request result, it adds the ID of the IO request that obtained the request result to the request result and writes the request result including the ID to the first result queue.

[0157] Furthermore, when the first application determines that a certain request result obtained from the first result queue includes the first ID, the first application determines that the request result is a request result of the first IO request, that is, a first request result.

[0158] Then, the first application can execute the subsequent process of the specific task performed by the first application according to the first request result, which is not described in detail in the embodiment of the present application.

[0159] Thus, through the method described in steps 101 to 105, the purpose of processing the TA's I / O requests in the TEE is achieved by using the xtasklet framework created in the electronic device REE and TEE. In this way, when the TA needs to execute multiple I / O requests, the worker thread pool on the REE side of the xtasklet framework can process these I / O requests in parallel, thereby improving the efficiency of processing the TA's I / O requests on the TEE side through the RER.

[0160] In some embodiments, in order to save the occupation of electronic device resources (such as CPU resources, memory resources, etc.) by the REE-side working thread pool in the xtasklet framework, in combination with Figure 6 and referring to Figure 7, the above method further includes step 106 after step 4.

[0161] Step 106: The first working thread sets its own state to a sleep state.

[0162] The first working process sets its own state to a dormant state, indicating that the first working process has entered a dormant state. As an example, the first working process can enter the dormant state by calling a sleep() function.

[0163] In a possible implementation, after writing the first request result into the first result queue, the first worker thread immediately sets its own state to a dormant state.

[0164] In another possible implementation, after writing the first request result into the first result queue, the first working thread repeats steps 102 to 104 until the first task queue returns status information that the first task queue is empty to the first working process when the first working thread executes step 102, and then the first working thread immediately sets its own status to the sleep state.

[0165] In this way, for idle working threads that have processed IO requests, the method of the embodiment of the present application puts these working threads into a dormant state, which can reduce the occupation of electronic device resources (such as CPU resources, memory resources, etc.) by the working threads.

[0166] The following describes the detailed process of "the first detection thread detecting whether the first task queue is empty and, based on the detection result, instructing a worker thread in the first worker thread pool to obtain an IO request from the first task queue." Referring to FIG8 , FIG8 shows a schematic diagram of a process for a worker thread to obtain an IO request from the first task queue, provided in an embodiment of the present application. The process includes the following steps.

[0167] Step 201: The first detection thread detects whether the first task queue is empty.

[0168] Optionally, the first detection thread can continue or periodically detect whether the first task queue is empty after startup. For example, the first detection thread can periodically detect whether the first task queue is empty with 100 milliseconds as the cycle duration after startup. In the process of whether the first detection thread periodically detects the first task queue as empty, the first detection thread can be in a dormant state during the interval in which the first detection thread detects whether the first task queue is empty in two adjacent cycles, so that the occupancy of electronic equipment resources (such as CPU resources, memory resources etc.) can be saved.

[0169] For detailed description of how the first detection thread detects whether the first task queue is empty, please refer to the description of how the detection thread detects whether the first result queue is not empty in step 1052, which will not be repeated here.

[0170] When the first detection thread detects that the first task queue is empty, the first detection thread repeatedly continues to execute step 201. Optionally, when the first detection thread detects that the first task queue is empty, the first detection thread further executes step 205.

[0171] When the first detection thread detects that the first task queue is not empty, the first detection thread executes steps 202 to 204 .

[0172] Step 202: When the first detection thread detects that the first task queue is not empty, it determines whether there is a dormant worker thread in the first worker thread pool.

[0173] When the first detection thread detects that the first task queue is not empty, it indicates that there are pending IO requests in the first task queue.

[0174] As can be seen from step 106, the worker threads in the first worker thread pool will enter a dormant state after processing an IO request or when an IO request cannot be obtained from the first task queue. That is, the worker threads in the first worker thread pool are configured to be in a dormant state when not obtaining an IO request from the first task queue and processing the IO request. Therefore, the first worker thread pool includes worker threads in two states: a dormant state and a worker thread that is processing an IO request. In this case, after determining that there are pending IO requests in the first task queue, the first detection thread also needs to determine whether there are dormant state worker threads in the first worker thread pool.

[0175] Specifically, the first detection thread may query the status information of each worker thread in the first worker thread pool to determine whether there is a worker thread in the first worker thread pool that is in a dormant state.

[0176] For example, for the first worker thread in the first worker thread pool, the first detection thread queries the state information of the first worker thread and finds that the value of the element indicating the ready state is 1, and then determines that the state of the first worker thread is the ready state.

[0177] For another example, for the second worker thread in the first worker thread pool, the first detection thread queries the state information of the second worker thread and finds that the value of the element indicating the sleep state is 1, then determines that the state of the second worker thread is the sleep state.

[0178] When the first detection thread determines that there is a worker thread in the first worker thread pool in a dormant state, the first detection thread executes step 203 .

[0179] When the first detection thread determines that there is no worker thread in the first worker thread pool in the dormant state, the first detection thread executes step 204 .

[0180] Step 203: When it is determined that there is a dormant thread in the first work thread pool, the first detection thread sends a wake-up instruction to the dormant work thread in the first work thread pool to instruct the dormant work thread in the first work thread pool to switch the state from the dormant state to the ready state.

[0181] As an example, the first detection thread may send a wake-up instruction to the worker thread in the dormant state in the first worker thread pool through the pthread function to instruct the worker thread in the dormant state in the first worker thread pool to switch the state from the dormant state to the ready state.

[0182] In response, the worker thread in the first worker thread pool that is in a dormant state receives the wake-up instruction sent by the first detection thread and, in response to the wake-up instruction, switches its state from the dormant state to the ready state. Then, the worker thread that has switched to the ready state executes steps 102 to 104 and step 106 above.

[0183] For example, for a first worker thread in the first worker thread pool that is in a dormant state, the first worker thread receives a wake-up instruction sent by the first detection thread and, in response to the wake-up instruction, switches its state from the dormant state to the ready state. The first worker thread then executes steps 102 to 104 and step 106 above.

[0184] Step 204: After determining that no threads in the dormant state exist in the first working thread pool, the first detection thread creates a first preset number of working threads in the first working thread pool.

[0185] The first detection thread determines that there are no threads in a dormant state in the first work pool, indicating that all the work threads in the current first work thread pool are performing operations to process IO requests. In this case, in order to improve the processing efficiency of the IO requests of the first application in the first task queue, the first detection thread creates a first preset number of work threads in the first work thread pool. Then, the work thread newly created by the first detection thread executes the above-mentioned steps 102 to 104 and step 106. For example, when the first work thread mentioned above is one of the work threads newly created by the first detection thread, after the first work thread is created, the above-mentioned steps 102 to 104 and step 106 are executed.

[0186] As an example, assuming that the first work thread pool originally includes X work threads, where X is a positive integer, when the first detection thread determines that there are no threads in the first work pool that are in a dormant state, it means that at this time, the X work threads in the first work thread pool are all executing operations to process IO requests in the first task queue. In this case, the first detection thread creates Z work threads in the first work thread pool, where Z is a positive integer. In this case, the first work thread pool includes X+Z=Y work threads, and the Y work threads can all be used to execute the above-mentioned steps 102 to 104 and step 106 to improve the processing efficiency of IO requests.

[0187] Step 205: When the first detection thread detects that the first task queue is empty, a second preset number of worker threads in the first worker thread pool is destroyed.

[0188] When the first detection thread detects that the first task queue is empty, or when the first detection thread detects that the first task queue is empty within a preset number of consecutive detection cycles, it indicates that the first application has no recent IO request written into the first task queue. Here, the embodiment of the present application does not specifically limit the preset number.

[0189] In this case, the first detection thread destroys a second preset number of worker threads in the first worker thread pool to release resources of the electronic device (such as CPU resources, memory resources, etc.). In this embodiment of the present application, there is no specific limitation on the value of the second preset number, and the second preset number only needs to be less than the number of worker threads currently included in the first worker thread pool.

[0190] Through steps 201 to 205, the embodiment of the present application can timely destroy redundant work threads in the first work thread pool when there are no IO requests in the first task queue, and can wake up the dormant work threads in the first work thread pool to process the IO requests in the first task queue when the first detection thread detects that there are IO requests in the first task queue. Through this method, the occupation of resources (such as CPU resources, memory resources, etc.) in the electronic device by work threads can be effectively reduced.

[0191] In some other embodiments, since the frequency with which the first application writes IO requests to the first task queue varies over time, in order to save the first detection thread from occupying electronic device resources, the first detection thread, in the process of periodically detecting whether the first task queue is empty, can adjust the cycle length for detecting whether the first task queue is empty according to the frequency with which the first application writes IO requests to the first task queue. For example, the first detection thread detects the frequency with which the first application writes IO requests to the first task queue, obtains a detection result, and adjusts the cycle length for detecting the first task queue itself according to the detection result.

[0192] Optionally, in any detection cycle of periodically detecting whether the first task queue is empty, the first detection thread can detect whether the first task queue is empty by the third preset number of consecutive times, and obtain the third preset number of detection results, and the detection result of the third preset number can be used to characterize the frequency of the first application writing IO requests to the first task queue. And then, the first detection thread adjusts the cycle duration of the first task queue itself according to the third preset number of detection results. It should be understood that the present application does not specifically limit the value of the third preset number (for example, the third preset number value is 1000), but the time required for the first detection thread to detect whether the first task queue is empty for the third preset number of consecutive times is much less than the duration of a detection cycle in which the first detection thread detects whether the first task queue is empty.

[0193] In one example, when the number of detection results indicating that the first task queue is not empty in the third preset number of detection results exceeds the first threshold, it means that the frequency of the first application writing IO requests to the first task queue is high, so the first detection thread shortens its own cycle duration for detecting whether the first task queue is empty, for example, the first detection thread shortens its own cycle duration for detecting whether the first task queue is empty by the first preset step length. Among them, the embodiment of the present application does not specifically limit the value of the first threshold. For example, the first threshold can be a natural number less than the third preset number, or the first threshold can be a preset percentage of the third preset number, such as the first threshold is 5% of the third preset number, etc., but is not limited to this. In addition, the embodiment of the present application does not specifically limit the value of the first preset step length, for example, the first preset step length can be 1 millisecond, 2 milliseconds, 10 milliseconds, etc., but is not limited to this.

[0194] In another example, when the number of detection results indicating that the first task queue is empty in the third preset number of detection results exceeds the second threshold value, the first detection thread increases the cycle duration of its own detection of whether the first task queue is empty, for example, the first detection thread increases the cycle duration of its own detection of whether the first task queue is empty with a second preset step length. Among them, the embodiment of the present application does not specifically limit the value of the second threshold value. For example, the second threshold value can be a natural number less than the third preset number, or the second threshold value is a preset percentage of the third preset number, such as the second threshold value is 98% of the third preset number, etc., but is not limited to this. In addition, the embodiment of the present application does not specifically limit the value of the second preset step length, for example, the second preset step length is 1 millisecond, 2 milliseconds, 10 milliseconds, etc., but is not limited to this.

[0195] It should be understood that the first preset step size and the second preset step size may be the same or different, and this embodiment of the present application does not limit this.

[0196] It should also be understood that, in order to ensure that the first detection thread detects the first task queue, when the first detection thread adjusts the duration of the detection cycle of itself detecting whether the first task queue is empty according to the frequency of writing IO requests to the first task queue, the first detection thread is provided with a maximum cycle duration (e.g., 100 milliseconds). When the detection cycle duration after the adjustment of the first detection thread is equal to the maximum cycle duration, the adjustment of the duration of the detection cycle of the first detection thread detecting whether the first task queue is empty is stopped.

[0197] Like this, by adjusting the cycle duration that the first detection thread detects whether the first task queue is empty according to the frequency of writing IO requests to the first task queue, it is possible to achieve when the frequency of writing IO requests to the first task queue is higher, shorten the cycle duration that the first detection thread detects whether the first task queue is empty, that is, improve the detection frequency that the first detection thread detects whether the first task queue is empty.And, by adjusting the cycle duration that the first detection thread detects whether the first task queue is empty according to the frequency of writing IO requests to the first task queue, it is possible to achieve when the frequency of writing IO requests to the first task queue is lower, increase the cycle duration that the first detection thread detects whether the first task queue is empty, that is, reduce the detection frequency that the first detection thread detects whether the first task queue is empty.Like this, can on the basis of guaranteeing the efficiency of processing IO requests in the first task queue, also effectively save the first detection thread to the occupancy of electronic equipment resources.

[0198] It should be noted that the order of the steps of the methods provided in the embodiments of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. Any method that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application, and therefore will not be described in detail.

[0199] The above mainly introduces the solution provided in the embodiment of the present application from the perspective of method.

[0200] In order to achieve the above functions, as shown in Figure 9, Figure 9 shows a structural diagram of a processing device 900 for IO requests provided by an embodiment of the present application. The processing device 900 is applied to an electronic device, and the first execution environment of the electronic device includes a first working thread pool. The first working thread pool communicates with the first application running in the second execution environment of the electronic device through a first task queue and a first result queue. The first task queue is used to store the IO requests of the first application, and the first result queue is used to store the request results of the IO requests. The first working thread pool includes multiple working threads for processing IO requests in the first task queue. The processing device 900 is used to execute the above-mentioned IO request processing method, for example, for executing the part of the method shown in Figure 6, Figure 7 or Figure 8 that is executed in the first execution environment of the electronic device. Among them, the processing device 900 may include an acquisition unit 901, an execution unit 902 and a write unit 903.

[0201] An acquisition unit 901 is configured to acquire I / O requests from a first task queue using a worker thread in a first worker thread pool. For a first I / O request acquired by a first worker thread from a first task queue, an execution unit 902 is configured to execute the first I / O request using the first worker thread to obtain a first request result. The first worker thread is any worker thread in the first worker thread pool that acquires the I / O request. A writing unit 9003 is configured to write the first request result into a first result queue using the first worker thread.

[0202] As an example, in combination with FIG. 6 or FIG. 7 , the acquiring unit 901 may be used to execute step 102 , the executing unit 902 may be used to execute step 103 , and the writing unit 903 may be used to execute step 104 .

[0203] Optionally, the first execution environment of the electronic device further includes a second worker thread pool, which communicates with the second application in the second execution environment via a second task queue and a second result queue. The second task queue is used to store I / O requests from the second application, and the second result queue is used to store request results of I / O requests from the second task queue. The second worker thread pool includes multiple worker threads, and the worker threads in the second worker thread pool are used to process I / O requests in the second task queue and write the obtained results to the second result queue.

[0204] Optionally, the first execution environment of the electronic device also includes a detection thread corresponding to the first worker thread pool. In this case, before the acquisition unit 901 obtains IO requests from the first task queue respectively through the worker threads in the first worker thread pool, the processing device 900 also includes: a receiving unit 904, which is used to receive a wake-up instruction sent by the detection thread through the worker threads in the first worker thread pool that are in a dormant state. A switching unit 905 is used to respond to the wake-up instruction and switch the worker threads in the first worker thread pool that are in a dormant state from a dormant state to a ready state. The detection thread is used to detect whether the first task queue is empty, and to determine whether there are dormant worker threads in the first worker thread pool when it is detected that the first task queue is not empty, and to send a wake-up instruction to the dormant worker threads in the first worker thread pool when it is determined that there are dormant worker threads in the first worker thread pool. The acquisition unit 901 is specifically used to obtain IO requests from the first task queue respectively through the worker threads in the first worker thread pool that have switched from a dormant state to a ready state.

[0205] As an example, in conjunction with FIG. 8 , the receiving unit 904 and the switching unit 905 may be configured to respond to step 203 .

[0206] Optionally, when there is no dormant worker thread in the first worker thread pool, the detection thread is further configured to create a first preset number of worker threads in the first worker thread pool. The acquisition unit 901 is specifically configured to acquire IO requests from the first task queue using the newly created worker threads in the first worker thread pool.

[0207] Optionally, when the above-mentioned detection thread is used to periodically detect whether the first task queue is empty, the detection thread is also used to detect the frequency of writing IO requests to the first task queue in each cycle to obtain the detection result of each cycle, and the detection result is used to adjust the cycle duration of the detection thread to detect whether the first task queue is empty.

[0208] Optionally, the detection thread is further configured to destroy a second preset number of dormant worker threads in the first worker thread pool when detecting that the first task queue is empty.

[0209] Optionally, after the writing unit 903 writes the first request result into the first result queue through the first working thread, or after the writing unit 903 writes the first request result into the first result queue through the first working thread, and when the obtaining unit 901 again obtains the IO request from the first task queue through the first working thread and the first working thread receives status information that the queue returned by the first task queue is empty, the switching unit 905 is also used to set the status of the first working thread to a sleep state through the first working thread.

[0210] As an example, in conjunction with FIG. 7 , the switching unit 905 may be configured to perform step 106 .

[0211] Optionally, the IO request of the first application includes a disk IO request. In this case, the first task queue is used to store the disk IO request of the first application.

[0212] Optionally, the IO request of the first application also includes a network IO request. In this case, the first execution environment of the electronic device also includes a third work thread pool. The third work thread pool communicates with the first application through a third task queue and a third result queue. The third task queue is used to store the network IO requests of the first application, and the third result queue is used to store the request results of the network IO requests in the third task queue. The third work thread pool includes multiple work threads. The work threads in the third work thread pool are used to process the network IO requests in the third task queue and write the obtained request results to the third result queue.

[0213] Optionally, the security level of the first execution environment in the electronic device is different from the security level of the second execution environment.

[0214] Optionally, the first execution environment of the electronic device is REE, and the second execution environment is TEE.

[0215] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation of any of the processing devices 900 provided above and the description of the beneficial effects can refer to the above corresponding method embodiments, which will not be repeated here.

[0216] As an example, with reference to FIG12 described below, the functions implemented by the acquisition unit 901, execution unit 902, writing unit 903, and switching unit 905 in the processing device 900 can be implemented by the processor 1201 in FIG12 executing the program code in the memory 1202 in FIG12. The functions implemented by the receiving unit 904 can be implemented by the internal interface in the communication interface 1203 shown in FIG12.

[0217] As shown in Figure 10, Figure 10 shows a structural diagram of another IO request processing device 1000 provided in an embodiment of the present application. The processing device 1000 is applied to an electronic device, and a first application is running in the second execution environment of the electronic device. The first application communicates with the first execution environment of the electronic device through a first task queue and a first result queue. The first task queue is used to store the IO requests of the first application, and the first result queue is used to store the request results of the IO requests in the first task queue. The processing device 1000 is used to execute the above-mentioned IO request processing method, for example, for executing the part of the method shown in Figure 6, Figure 7 or Figure 8 that is executed in the second execution environment of the electronic device. Among them, the processing device 1000 may include a writing unit 1001 and an acquisition unit 1002.

[0218] Writing unit 1001 is configured to write a first IO request to a first task queue via a first application. The first IO request is any IO request written by the first application to the first task queue. Acquisition unit 1002 is configured to acquire a first request result of the first IO request from a first result queue via the first application. The first request result is a request result obtained after a worker thread in a worker thread pool corresponding to the first application in a first execution environment processes the first IO request.

[0219] As an example, in combination with FIG. 6 or FIG. 7 , the writing unit 1001 may be used to execute step 101 , and the acquiring unit 1002 may be used to execute step 105 .

[0220] Optionally, a second application is also running in the second execution environment of the electronic device. The second application communicates with the first execution environment through a second task queue and a second result queue. The second task queue is used to store I / O requests of the second application, and the second result queue is used to store request results of I / O requests in the second task queue. The request results are request results obtained after a worker thread in a worker thread pool corresponding to the second application in the first execution environment processes the I / O requests in the second task queue.

[0221] Optionally, the IO request of the first application includes a disk IO request. In this case, the first task queue is used to store the disk IO request of the first application.

[0222] Optionally, the IO request of the first application also includes a network IO request. In this case, the first application further communicates with the first execution environment through a third task queue and a third result queue. The third task queue is used to store the network IO request of the first application, and the third result queue is used to store the request results of the network IO request in the third task queue. The request result is the request result obtained after the worker thread in the worker thread pool corresponding to the first application in the first execution environment processes the IO request in the third task queue.

[0223] Optionally, the security level of the first execution environment in the electronic device is different from the security level of the second execution environment.

[0224] Optionally, the first execution environment of the electronic device is REE, and the second execution environment is TEE.

[0225] Optionally, after the writing unit 1001 writes the first IO request to the first task queue via the first application, the processing device 1000 further includes: a receiving unit 1003, configured to receive a first ID of the first IO request returned by the first task queue. A determining unit 1004, configured to determine a request result including the first ID from the request results obtained from the first result queue as the first request result. Each request result in the first result queue includes the ID of the IO request that obtained each request result.

[0226] As an example, in conjunction with FIG6 , the receiving unit 1003 may be configured to execute step 1051 , and the determining unit 1004 may be configured to execute step 1053 .

[0227] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation of any of the processing devices 1000 provided above and the description of the beneficial effects can refer to the above corresponding method embodiments, which will not be repeated here.

[0228] As an example, with reference to FIG12 described below, the functions implemented by the writing unit 1001, the obtaining unit 1002, and the determining unit 1004 in the processing device 1000 can be implemented by the processor 1201 in FIG12 executing the program code in the memory 1202 in FIG12. The functions implemented by the receiving unit 1003 can be implemented by the internal interface of the communication interface 1203 shown in FIG12.

[0229] As shown in Figure 11, Figure 11 shows a schematic diagram of the structure of another IO request processing device 1100 provided in an embodiment of the present application. Processing device 1100 is used to execute the above-mentioned IO request processing method, for example, for executing the method shown in Figure 6, Figure 7, or Figure 8. Processing device 1100 includes a first processing unit 1101 and a second processing unit 1102.

[0230] The first processing unit 1101 is configured to run a first execution environment and execute the method for processing IO requests described above, such as executing the portion of the method shown in FIG. 6 , FIG. 7 , or FIG. 8 that is executed in the first execution environment. The second processing unit 1102 is configured to run a second execution environment and execute the method for processing IO requests described above, such as executing the portion of the method shown in FIG. 6 , FIG. 7 , or FIG. 8 that is executed in the second execution environment.

[0231] Optionally, the security level of the first execution environment in the electronic device is different from the security level of the second execution environment.

[0232] Optionally, the first execution environment of the electronic device is REE, and the second execution environment is TEE.

[0233] For the detailed description of the above optional manners, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation of any of the processing devices 1100 provided above and the description of the beneficial effects can refer to the above corresponding method embodiments, which will not be repeated here.

[0234] It should be readily apparent to those skilled in the art that, in combination with the units and algorithmic steps of the various examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is performed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0235] It should be noted that the division of modules / units in Figures 9, 10, and 11 is schematic and merely a logical functional division. In actual implementation, other divisions may be employed. For example, two or more functions may be integrated into a single processing module. Such integrated modules may be implemented in either hardware or software functional modules.

[0236] An embodiment of the present application provides an electronic device. The electronic device is used to implement some or all of the functions of the method provided in the embodiment of the present application. In the embodiment of the present application, a first execution environment and a second execution environment are running in the electronic device, wherein the security level of the first execution environment is different from the security level of the second execution environment. In some examples, the first execution environment is REE and the second execution environment is TEE. By executing the method described above in the embodiment of the present application on an electronic device running the first execution environment and the second execution environment, the efficiency of the application in the second execution environment of the electronic device in processing IO requests through the first execution environment can be improved.

[0237] Figure 12 shows a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. As shown in Figure 12, the electronic device 1200 includes a processor 1201, a memory 1202, a communication interface 1203, and a bus 1204. The processor 1201, the memory 1202, and the communication interface 1203 are connected to each other via the bus 1204.

[0238] The processor 1201 may include a general-purpose processor and / or a dedicated hardware chip. The general-purpose processor may include: a central processing unit (CPU), a microprocessor or a graphics processing unit (GPU). The CPU is, for example, a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The dedicated hardware chip is a hardware module for high-performance processing. The dedicated hardware chip includes at least one of a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or a network processor (NP). The processor 1201 may also be an integrated circuit chip with signal processing capabilities. During implementation, some or all of the functions of the method of the present application may be completed by the integrated logic circuit of the hardware in the processor 1201 or instructions in the form of software.

[0239] The memory 1202 is used to store computer programs, which include an operating system 1202a and executable code (i.e., program instructions) 1202b. The memory 1202 may be, for example, a read-only memory or other type of static storage device that can store static information and instructions, or a random access memory or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory, a read-only optical disc or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired executable code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these. For example, the memory 1202 is used to store IO requests and the results of IO requests. The memory 1202 may exist independently and be connected to the processor 1201 via the bus 1204. Alternatively, the memory 1202 and the processor 1201 may be integrated together. The memory 1202 can store executable code. When the executable code stored in the memory 1202 is executed by the processor 1201, the processor 1201 is used to perform some or all of the functions of the method provided in the embodiments of the present application. For the implementation of the process executed by the processor 1201, please refer to the relevant description of the aforementioned embodiments. The memory 1202 may also include software modules and data required for other running processes, such as the operating system.

[0240] The communication interface 1203 uses a transceiver module, such as, but not limited to, a transceiver, to communicate with other devices or communication networks. For example, the communication interface 1203 can be any one or a combination of the following devices: a network interface (such as an Ethernet interface), a wireless network card, or other device with network access capabilities.

[0241] The communication interface 1203 also includes a hardware or software interface for implementing communication between various device modules within the electronic device 1200. This type of interface can be called an internal interface for communication in the electronic device 1200.

[0242] The bus 1204 is any type of communication bus for interconnecting the internal components of the electronic device (e.g., the memory 1202, the processor 1201, and the communication interface 1203). For example, a system bus. The embodiment of the present application uses the interconnection of the above-mentioned components within the electronic device via the bus 1204 as an example. Optionally, the above-mentioned components within the electronic device 1200 can also be connected to each other in a communication manner other than the bus 1204. For example, the above-mentioned components within the electronic device 1200 are interconnected via an internal logical interface.

[0243] It should be noted that the above-mentioned multiple devices can be respectively arranged on independent chips, or at least partially or completely arranged on the same chip. Whether each device is independently arranged on different chips or integrated on one or more chips often depends on the needs of product design. The embodiments of the present application do not limit the specific implementation form of the above-mentioned devices. The descriptions of the processes corresponding to the above-mentioned figures have different focuses. For parts that are not described in detail in a certain process, please refer to the relevant descriptions of other processes.

[0244] In the above embodiments, all or part of the methods can be implemented through software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the methods can be implemented in the form of a computer program product. The computer program product that provides a program development platform includes one or more computer instructions. When these computer program instructions are loaded and executed on an electronic device, all or part of the functions of the methods provided in the embodiments of the present application are implemented in whole or in part.

[0245] Furthermore, computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium stores computer program instructions that provide a program development platform.

[0246] An embodiment of the present application also provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium. The computer-readable storage medium includes program instructions. When the program instructions are executed on a computer, a computer system or a processor, the computer, the computer system or the processor implements the method provided in the embodiment of the present application.

[0247] The embodiments of the present application also provide a computer program product comprising instructions, which, when executed on a computer, a computer system or a processor, enables the computer, the computer system or the processor to implement the method provided in the embodiments of the present application.

[0248] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by instructing the relevant hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk, or an optical disk, etc.

[0249] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0250] An embodiment of the present application also provides a chip, which includes a processor, in which the first execution environment and the second execution environment described above are run, and is used to execute the IO request processing method described above, such as the method shown in Figure 6, Figure 7 or Figure 8.

[0251] Exemplarily, the chip further includes an input interface, an output interface, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The memory is used to store the aforementioned program instructions or codes, as well as the aforementioned IO requests and their results.

[0252] In the embodiments of the present application, the terms "first", "second" and "third" are used for descriptive purposes only and should not be understood as indicating or implying relative importance. The term "at least one" refers to one or more, and the term "plurality" refers to a plurality, unless otherwise expressly limited.

[0253] In this application, the term "and / or" simply describes an association between related objects, indicating that three possible relationships exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0254] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0255] It should be understood that determining B based on A does not mean determining B based solely on A. B can also be determined based on A and / or other information.

[0256] It will also be understood that the term “comprise” (also known as “includes,” “including,” “comprises,” and / or “comprising”) when used in this specification specifies the presence of stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0257] It should also be understood that in the various embodiments of the present application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0258] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the concepts and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for processing an input / output (IO) request, characterized in that: Applied to an electronic device, wherein a first execution environment of the electronic device includes a first working thread pool, the first working thread pool communicates with a first application running in a second execution environment of the electronic device through a first task queue and a first result queue, the first task queue is used to store IO requests of the first application, the first result queue is used to store request results of the IO requests, and the first working thread pool includes a plurality of working threads for processing IO requests in the first task queue; the method includes: The worker threads in the first worker thread pool respectively obtain IO requests from the first task queue; For a first IO request obtained by a first worker thread from the first task queue, the first worker thread executes the first IO request to obtain a first request result; wherein the first worker thread is any worker thread in the first worker thread pool that obtains the IO request; The first working thread writes the first request result into the first result queue.

2. The method according to claim 1, characterized in that The first execution environment also includes a second work thread pool, which communicates with a second application in the second execution environment through a second task queue and a second result queue. The second task queue is used to store IO requests of the second application, and the second result queue is used to store request results of the IO requests of the second task queue. The second work thread pool includes multiple work threads, and the work threads in the second work thread pool are used to process IO requests in the second task queue and write the obtained results into the second result queue.

3. The method according to claim 1 or 2, characterized in that The first execution environment further includes a detection thread corresponding to the first working thread pool. Before the working threads in the first working thread pool respectively obtain IO requests from the first task queue, the method further includes: A worker thread in a dormant state in the first worker thread pool receives a wake-up instruction sent by the detection thread; In response to the wake-up instruction, the worker thread in the first worker thread pool that is in a dormant state switches from the dormant state to the ready state; The detection thread is used to detect whether the first task queue is empty, and to determine whether there is a dormant worker thread in the first worker thread pool when it is detected that the first task queue is not empty, and to send the wake-up instruction to the dormant worker thread in the first worker thread pool when it is determined that there is a dormant worker thread in the first worker thread pool; The worker threads in the first worker thread pool respectively obtain IO requests from the first task queue, including: The worker threads in the first worker thread pool whose states are switched from the sleep state to the ready state respectively obtain IO requests from the first task queue.

4. The method according to claim 3, characterized in that In the case that there is no worker thread in a dormant state in the first worker thread pool, the detection thread is further used to create a first preset number of worker threads in the first worker thread pool; the worker threads in the first worker thread pool respectively obtain IO requests from the first task queue, including: The newly created worker threads in the first worker thread pool respectively obtain IO requests from the first task queue.

5. The method according to claim 3 or 4, characterized in that In the case where the detection thread is used to periodically detect whether the first task queue is empty, the detection thread is also used to detect the frequency of writing IO requests to the first task queue in each cycle to obtain the detection result of each cycle, and the detection result is used to adjust the cycle duration of the detection thread to detect whether the first task queue is empty.

6. The method according to claim 3, characterized in that The detection thread is also used to destroy a second preset number of dormant worker threads in the first worker thread pool when detecting that the first task queue is empty.

7. The method according to any one of claims 1 to 6, characterized in that After the first worker thread writes the first request result into the first result queue, or after the first worker thread writes the first request result into the first result queue, when the queue is empty when obtaining the IO request from the first task queue again, the method further includes: The first worker thread sets the state of the first worker thread to a sleep state.

8. The method according to any one of claims 1 to 7, characterized in that The IO request of the first application includes a disk IO request, and the first task queue is used to store the disk IO request.

9. The method according to claim 8, characterized in that The IO requests of the first application also include network IO requests. The first execution environment also includes a third work thread pool. The third work thread pool communicates with the first application through a third task queue and a third result queue. The third task queue is used to store the network IO requests. The third result queue is used to store the request results of the network IO requests in the third task queue. The third work thread pool includes multiple work threads. The work threads in the third work thread pool are used to process the network IO requests in the third task queue and write the obtained request results into the third result queue.

10. The method according to any one of claims 1 to 9, characterized in that The security level of the first execution environment is different from the security level of the second execution environment.

11. The method according to any one of claims 1 to 10, characterized in that The first execution environment is a rich execution environment (REE), and the second execution environment is a trusted execution environment (TEE).

12. A method for processing an input / output (IO) request, characterized in that: The method is applied to an electronic device, wherein a first application is running in a second execution environment of the electronic device, the first application communicates with the first execution environment of the electronic device through a first task queue and a first result queue, the first task queue is used to store IO requests of the first application, and the first result queue is used to store request results of the IO requests in the first task queue; the method comprises: The first application writes a first IO request to the first task queue, where the first IO request is any IO request written by the first application to the first task queue; The first application obtains a first request result of the first IO request from the first result queue, where the first request result is a request result obtained after a worker thread in a worker thread pool corresponding to the first application in the first execution environment processes the first IO request.

13. The method according to claim 12, characterized in that A second application is also running in the second execution environment. The second application communicates with the first execution environment through a second task queue and a second result queue. The second task queue is used to store IO requests of the second application. The second result queue is used to store request results of the IO requests in the second task queue. The request result is the request result obtained after the working thread in the working thread pool corresponding to the second application in the first execution environment processes the IO request in the second task queue.

14. The method according to claim 12 or 13, characterized in that The IO request of the first application includes a disk IO request, and the first task queue is used to store the disk IO request.

15. The method according to claim 14, characterized in that The IO request of the first application also includes a network IO request. The first application also communicates with the first execution environment through a third task queue and a third result queue. The third task queue is used to store the network IO request, and the third result queue is used to store the request result of the network IO request in the third task queue. The request result is the request result obtained after the working thread in the working thread pool corresponding to the first application in the first execution environment processes the IO request in the third task queue.

16. The method according to any one of claims 12 to 15, characterized in that The security level of the first execution environment is different from the security level of the second execution environment.

17. The method according to any one of claims 12 to 16, characterized in that The first execution environment is a rich execution environment (REE), and the second execution environment is a trusted execution environment (TEE).

18. The method according to any one of claims 12 to 17, characterized in that After the first application writes the first IO request to the first task queue, the method further includes: Receive a first identifier ID of the first IO request returned by the first task queue; The first application obtains the first request result of the first IO request from the first result queue, including: The request results including the first ID among the request results obtained from the first result queue are determined as the first request results; wherein each request result of the first result queue includes the ID of the IO request for obtaining each request result.

19. A device for processing input and output (IO) requests, characterized in that: include: A first processing unit, configured to run a first execution environment, and to execute the method according to any one of claims 1 to 11; The second processing unit is configured to run a second execution environment and to execute the method as claimed in any one of claims 12 to 18.

20. The device according to any one of claims 19, characterized in that The security level of the first execution environment is different from the security level of the second execution environment.

21. The device according to claim 19 or 20, characterized in that The first execution environment is a rich execution environment (REE), and the second execution environment is a trusted execution environment (TEE).

22. An electronic device, characterized in that: include: One or more processors and a memory, wherein the one or more processors are configured to read a first program instruction in the memory to run a first execution environment and execute the method as described in any one of claims 1 to 11; the one or more processors are also configured to read a second program instruction in the memory to run a second execution environment and execute the method as described in any one of claims 12 to 18.

23. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes program instructions. When the program instructions are executed on a computer or a processor, the computer or the processor is caused to perform the method according to any one of claims 1 to 18.

24. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device, the computing device is caused to perform the method according to any one of claims 1 to 18.

Images