Remote procedure call virtualization

Abstract

Various embodiments include a method for implementing remote procedure call (RPC) in a processor of a computing device. Embodiments may include a first processor configured to execute a plurality of guest virtual machines (GVMs) in parallel. Embodiments may include receiving, by a first virtual RPC module executed by a GVM of the plurality of GVMs, a first plurality of RPC requests from a plurality of RPC sources concurrently executed by the GVM; generating, by the first virtual RPC module, a plurality of RPC request messages from the first plurality of RPC requests; transmitting the plurality of RPC request messages from the first virtual RPC module to a memory of the computing device; retrieving, by a second virtual RPC module executed by the processor, the plurality of RPC request messages from the memory; and generating, by the second virtual RPC module, a second plurality of RPC requests for the plurality of RPC request messages.

Description

Background Art

[0001] More and more functions are being integrated into a single controller. Different functions may affect each other and require different real-time capabilities, security levels, and other parameters. In a single operating system (OS) architecture, applications that implement complex algorithms can call remote procedure calls (RPCs) to offload computing tasks from the central processing unit (CPU) to the digital signal processor (DSP). In a multi-OS architecture (including a host OS and multiple guest OSs such as in an automotive system), different types of applications run on different OSes. In a multi-OS architecture system, applications that execute complex algorithms cannot call RPCs directly to the DSP. Summary of the invention

[0002] Various aspects of the present disclosure provide methods for implementing remote procedure calls (RPCs) and computing devices implementing such methods in a first processor of a computing device, wherein the first processor is configured to execute multiple client virtual machines (GVMs) in parallel. Various aspects may include: receiving a first plurality of RPC requests from multiple RPC sources concurrently executed by the at least one GVM through at least one first virtual RPC module executed by at least one of the multiple GVMs; generating a plurality of RPC request messages from the first plurality of RPC requests through the at least one first virtual RPC module; transmitting the plurality of RPC request messages from the at least one first virtual RPC module to a memory of the computing device; retrieving the plurality of RPC request messages from the memory through a second virtual RPC module executed by the first processor; and generating a second plurality of RPC requests for the plurality of RPC request messages through the second virtual RPC module.

[0003] In some aspects, receiving the first plurality of RPC requests may include receiving the first plurality of RPC requests concurrently.

[0004] In some aspects, the first plurality of RPC requests includes a first RPC request and a second RPC request from a first RPC source among the plurality of RPC sources, the first RPC request is directed to a second processor of the computing device and the second RPC request is directed to a third processor of the computing device, and generating the second plurality of RPC requests for the plurality of RPC request messages may include generating a third RPC request directed to the second processor and a fourth RPC request directed to the third processor.

[0005] In some aspects, the first plurality of RPC requests includes a first RPC request from a first RPC source among the plurality of RPC sources and a second RPC request from a second RPC source among the plurality of RPC sources, the first RPC request and the second RPC request are directed to a second processor of the computing device, and generating the second plurality of RPC requests for the plurality of RPC request messages may include generating a third RPC request directed to the second processor and a fourth RPC request directed to the second processor.

[0006] In some aspects, the at least one GVM includes a first GVM and a second GVM, the multiple RPC sources include the first GVM and the second GVM, and the first multiple RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, generating the multiple RPC request messages from the first multiple RPC requests may include generating a first RPC request message from the first RPC request and generating a second RPC request message from the second RPC request, transmitting the multiple RPC request messages from the at least one first virtual RPC module to the memory may include pushing the first RPC request message to a first queue for the first GVM and pushing the second RPC request message to a second queue for the second GVM, and retrieving the multiple RPC request messages from the memory through the second virtual RPC module may include retrieving the first RPC request message from the first queue for the first GVM and retrieving the second RPC request message from the second queue for the second GVM.

[0007] In some aspects, the at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, generating the plurality of RPC request messages from the first plurality of RPC requests may include generating a first RPC request message from the first RPC request by the first virtual RPC module executed by the first GVM, and generating a second RPC request message from the second RPC request by the first virtual RPC module executed by the second GVM, and transmitting the plurality of RPC request messages from the at least one first virtual RPC module to the memory may include transmitting the plurality of RPC request messages from the at least one first virtual RPC module to the memory via The first RPC request message is transmitted to the memory through the first virtual RPC module executed by the first GVM, and the second RPC request message is transmitted to the memory through the first virtual RPC module executed by the second GVM, and these aspects may also include: transmitting a first RPC request notification for the first GVM from the first virtual RPC module executed by the first GVM to the second virtual RPC module; and transmitting a second RPC request notification for the second GVM from the first virtual RPC module executed by the second GVM to the second virtual RPC module, wherein retrieving the multiple RPC request messages from the memory through the second virtual RPC module may include retrieving the first RPC request message from the memory in response to receiving the first RPC request notification, and retrieving the second RPC request message from the memory in response to receiving the second RPC request notification.

[0008] In some aspects, the multiple RPC sources include a first application and a second application, and the first multiple RPC requests include a first RPC request from the first application and a second RPC request from the second application, and generating the second multiple RPC requests for the multiple RPC request messages may include generating a third RPC request from the first application and generating a fourth RPC request from the second application. These aspects may also include: pushing the third RPC request to a first thread pool for the first application; and pushing the fourth RPC request to a second thread pool for the second application.

[0009] In some aspects, generating the multiple RPC request messages from the first multiple RPC requests may include using data of the multiple RPC request messages from a first buffer and buffer properties of the first buffer to generate the multiple RPC request messages, and generating the second multiple RPC requests from the multiple RPC request messages may include: mapping a second buffer using the buffer properties; storing the data of the multiple RPC request messages into the second buffer; and generating the second multiple RPC requests using the data of the multiple RPC request messages from the second buffer.

[0010] In some aspects, the first plurality of RPC requests includes at least one RPC request from a first RPC source in the plurality of RPC sources, and generating the plurality of RPC request messages from the first plurality of RPC requests may include using at least one file descriptor for the data of the at least one RPC request message from the first persistent buffer to generate the at least one RPC request message. Such aspects may include: mapping a second persistent buffer for use by the first RPC source; retrieving the data of the at least one RPC request message from the at least one RPC request message using the at least one file descriptor; storing the data of the at least one RPC request message to the second persistent buffer, wherein generating the second plurality of RPC requests from the plurality of RPC request messages may include using the data of the at least one RPC request message from the second persistent buffer to generate at least one RPC request of the second plurality of RPC requests.

[0011] Some aspects may also include: setting process attributes of the multiple RPC sources, wherein generating the multiple RPC request messages from the first multiple RPC requests may include generating the multiple RPC request messages from the first multiple RPC requests based on the process attributes, and using the process attributes from the multiple RPC request messages to set the process attributes for implementing the second multiple RPC requests.

[0012] Some aspects may also include: receiving a first plurality of RPC results for the second plurality of RPC requests; generating a plurality of RPC result messages from the first plurality of RPC results; transmitting the plurality of RPC result messages from the second virtual RPC module to the memory; retrieving the plurality of RPC result messages from the memory via the at least one first virtual RPC module; and transmitting the plurality of RPC result messages from the at least one first virtual RPC module to the plurality of RPC sources.

[0013] In some aspects, the at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, and generating the plurality of RPC result messages from the first plurality of RPC results may include generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result. , transmitting the multiple RPC result messages from the second virtual RPC module to the memory may include pushing the first RPC result message to the first queue of the first GVM, and pushing the second RPC result message to the second queue of the second GVM, and retrieving the multiple RPC result messages from the memory through the at least one first virtual RPC module may include retrieving the first RPC result message from the first queue of the first GVM through the first virtual RPC module executed by the first GVM, and retrieving the second RPC result message from the second queue of the second GVM through the first virtual RPC module executed by the second GVM.

[0014] In some aspects, the at least one GVM includes a first GVM and a second GVM, and the plurality of RPC sources include the first GVM and the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, the first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, generating the plurality of RPC result messages from the first plurality of RPC results may include generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result, and transmitting the plurality of RPC result messages from the second virtual RPC module to the memory may include transmitting the first RPC result message and the second RPC result message Transmitted to the memory, these aspects may also include: transmitting a first RPC result notification for the first GVM from the second virtual RPC module to the first virtual RPC module executed by the first GVM; and transmitting a second RPC result notification for the second GVM from the second virtual RPC module to the first virtual RPC module executed by the second GVM, wherein retrieving the multiple RPC result messages from the memory through the at least one first virtual RPC module may include: in response to receiving the first RPC result notification, retrieving the first RPC result message from the memory through the first virtual RPC module executed by the first GVM; and in response to receiving the second RPC result notification, retrieving the second RPC result message from the memory through the first virtual RPC module executed by the second GVM.

[0015] In some aspects, the first plurality of RPC requests includes a first RPC request from a first RPC source among the plurality of RPC sources, the second plurality of RPC requests includes a second RPC request derived from the first RPC request, the first plurality of RPC results for the second plurality of RPC requests includes a first RPC result for the second RPC request, generating the plurality of RPC result messages from the first plurality of RPC results may include generating a first RPC result message using at least one file descriptor for the first RPC result from a first persistent buffer, and retrieving the plurality of RPC result messages from the memory through the at least one first virtual RPC module may include retrieving the at least one file descriptor for the first RPC result from a second persistent buffer, these aspects may also include: releasing the first persistent buffer storing the at least one file descriptor for the first RPC result; and releasing the second persistent buffer storing the at least one file descriptor for the first RPC result.

[0016] In some aspects, the plurality of RPC sources include one or more of: a plurality of client virtual machines, a plurality of applications running on the client virtual machines, or at least one application running on each of the plurality of client virtual machines.

[0017] Additional aspects include a computing device including a processor configured to perform the operations of any of the methods outlined above. Additional aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause the processor to perform the operations of any of the methods outlined above. Additional aspects include a computing device having components for implementing the functionality of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate example embodiments of the various embodiments and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0019] Figure 1 is a component block diagram illustrating an example computing device suitable for implementing various embodiments.

[0020] Figure 2 is a perspective diagram illustrating an example multi-operating system (OS) architecture in a vehicle context suitable for implementing various embodiments.

[0021] Figure 3 is a component block diagram illustrating an example remote procedure call (RPC) virtualization system suitable for implementing various embodiments of a multi-OS architecture.

[0022] Figure 4A is a component block diagram illustrating an RPC virtualization system suitable for implementing various embodiments.

[0023] Figure 4B is a process flow diagram illustrating a method for RPC virtualization according to various embodiments.

[0024] Figure 5 is a component block diagram and signaling diagram illustrating an RPC virtualization system suitable for implementing various embodiments.

[0025] Figure 6 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0026] Figure 7 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0027] Figure 8is a component block diagram illustrating an example server suitable for implementing various embodiments.

[0028] 9A to 9C is a component block diagram illustrating an example embedded vehicle computing system suitable for implementing various embodiments. DETAILED DESCRIPTION

[0029] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0030] Various embodiments include methods for implementing remote procedure call (RPC) virtualization and computing devices for implementing such methods. Various embodiments may include converting RPC requests from applications on a client virtual machine (GVM) into virtual RPC request messages through a front-end RPC module, and transmitting the virtual RPC request messages to a back-end RPC module implemented on a host operating system. Some embodiments may include converting RPC results into virtual RPC result messages through a back-end RPC module, and transmitting the virtual RPC result messages to the front-end RPC module. Some embodiments may include enabling multiple RPC requests from multiple applications and / or GVMs to be implemented on one or more processors, such as digital signal processors (DSPs).

[0031] The term "computing device" is used herein to refer to a stationary computing device, including personal computers, desktop computers, stand-alone computers, workstations, supercomputers, mainframe computers, embedded computers (such as in vehicles and other larger systems), computerized vehicles (e.g., partially or fully autonomous ground, air, and / or water vehicles, such as passenger vehicles, commercial vehicles, recreational vehicles, military vehicles, drones, etc.), servers, multimedia computers, and game consoles. The terms "computing device" and "mobile computing device" are used herein interchangeably to refer to any or all of the following: a cellular telephone, a smart phone, a personal or mobile multimedia player, a personal data assistant (PDA), a laptop computer, a tablet computer, a convertible laptop / tablet computer (2-in-1 computer), a smartbook, an ultrabook, a netbook, a palmtop computer, a wireless email receiver, an Internet-enabled multimedia cellular telephone, a mobile game console, a wireless game controller, and similar personal electronic devices that include memory and a programmable processor.

[0032] For ease and clarity of explanation, although various embodiments are described in terms of code (e.g., processor executable instructions), similarly applicable to any data, such as code, program data, or other information stored in memory. The terms "code," "data," and "information" are used interchangeably herein and are not intended to limit the scope of the claims and specification to the types of code, data, or information used as examples when describing various embodiments.

[0033] The terms "guest operating system," "guest OS," "guest virtual machine," and "GVM" are used interchangeably herein to refer to a virtual instance of an operating system implemented on a processing device.

[0034] The automotive electronic and electrical architecture (EEA) is becoming more and more centralized. Currently, domain controllers integrate all functions of a domain into one controller. In the future, all functions may be controlled by one centralized vehicle computer. However, various functions may affect other different functions and require different real-time capabilities, security levels and other parameters. Implementing a guest virtual machine (GVM) in an EEA can be used to isolate different functions in one system on a chip (SoC). Therefore, the implementation of GVM is becoming more and more popular in automotive controllers.

[0035] However, the computational demands on functions such as artificial intelligence (AI) modules are increasing, and providing adequate performance for complex algorithms running on the GVM is increasingly important to the goal of maintaining overall functional performance. Co-processing, such as offloading work to a digital signal processor (DSP), can help with complex computational performance. Remote procedure calls (RPCs) can be used to transfer tasks to the DSP for execution and return results to the application.

[0036] In a single operating system (OS) system, an application can call RPC to offload computing tasks from a processor, such as a central processing unit (CPU), to a DSP. However, in a multi-OS architecture, multiple guest OSs can be implemented by a hypervisor in a manner isolated from a host OS. For example, a guest OS can be a GVM; however, an application executing on the GVM cannot directly call RPC to a DSP.

[0037] Various embodiments address and solve the above problems through RPC virtualization. In various embodiments, RPC virtualization can send RPC requests from the client OS to the host OS, and the host OS can call RPC to the DSP. RPC virtualization transfers RPC messages between the client OS and the host OS via shared memory, and interrupts are managed by the hypervisor. A client RPC module and a host RPC module can be implemented to enable RPC messages to be communicated between the client OS and the host OS. The client RPC module and the host RPC module can implement virtual queues for messages, and enable multiple RPC requests from any number and combination of applications executed on any number and combination of client OS to be implemented on any number and combination of DSPs. For example, a single application can issue multiple RPC requests that can be implemented by one or more DSPs. For another example, multiple applications executed on one or more client OSes can issue multiple RPC requests that can be implemented by one or more DSPs.

[0038] RPC virtualization can offload the tasks of applications on the GVM to the DSP, thereby reducing the workload of the GVM, which increases the efficiency of computing resource usage. Therefore, more and more complex algorithms can be executed on the SoC.

[0039] Figure 1 A system including a computing device 10 suitable for use with various embodiments is illustrated. Figure 1 , the computing device 10 may include a system on chip (SoC) 12 having a processor 14, a memory 16, a communication interface 18, a storage memory interface 20, a memory interface 34, a power manager 28, a clock controller 30, a processor interface 38, and an interconnect 32. The computing device 10 may also include a communication component 22 (such as a wired or wireless modem), a storage memory 24, an antenna 26 for establishing a wireless communication link, a memory 36, and a processor 40. The processors 14, 40 may include any of a variety of processing devices (e.g., multiple processor cores).

[0040] The term "system on chip" (SoC) is used herein to refer to a group of interconnected electronic circuits, typically but not exclusively including a processing device, a memory, and a communication interface. The processing device may include a variety of different types of processors 14, 40 and processor cores, such as general-purpose processors, central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), accelerated processing units (APUs), security processing units (SPUs), subsystem processors for specific components of the computing device (such as an image processor for a camera subsystem or a display processor for a display), auxiliary processors, single-core processors, multi-core processors, controllers, and microcontrollers. The processing device may further embody other hardware and hardware combinations, such as field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), other programmable logic devices, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. The integrated circuit may be configured so that the components of the integrated circuit reside on a single piece of semiconductor material (such as silicon).

[0041] The SoC 12 may include one or more processors 14. The computing device 10 may include more than one SoC 12, thereby increasing the number of processors 14 and processor cores. The computing device 10 may also include a processor 40 that is not integrated with the SoC 12. The processors 14, 40 may each be configured for a specific purpose that may be the same or different from the other processors 14, 40 of the computing device 10. One or more of the processors 14, 40 and processor cores of the same or different configurations may be grouped together. A group of processors 14, 40 or processor cores may be referred to as a multi-processor cluster.

[0042] The memory 16, 36 of the SoC 12 may be a volatile or non-volatile memory configured to store data and processor executable code for access by the processor 14, 40. The computing device 10 and / or the SoC 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memory, such as random access memory (RAM) or main memory, including static RAM (SRAM) and / or dynamic RAM (DRAM) or cache memory. These memories 16, 36 may be configured to temporarily hold a limited amount of data received from a data sensor or subsystem, data and / or processor executable code instructions loaded from the non-volatile memory 16, 24 to the memory 16 in anticipation of future access based on a variety of factors, and / or intermediate processing data and / or processor executable code instructions generated by the processor 14, 40 and temporarily stored for future quick access without being stored in the non-volatile memory 16, 24. Memory interface 34 and memory 36 may work in concert to allow computing device 10 to load and retrieve data and processor executable code on memory 36 .

[0043] The storage memory interface 20 and the storage memory 24 can work in concert to allow the computing device 10 to store data and processor executable code on a non-volatile storage medium. The storage memory 24 can be configured very similarly to the embodiment of the memory 16, where the storage memory 24 can store data or processor executable code for access by one or more of the processors 14, 40. The non-volatile storage memory 24 can retain information after the computing device 10 has been powered off. When power is restored and the computing device 10 restarts, the information stored on the storage memory 24 is available to the computing device 10. The storage memory interface 20 can control access to the storage memory 24 and allow the processors 14, 40 to read data from the storage memory 24 and write data to the storage memory.

[0044] The power manager 28 may be configured to control the power state of components of the SoC 12 and / or the power delivery to the components of the SoC. In some embodiments, the power manager 28 may be configured to signal a power state to the components of the SoC 12 to prompt the components of the SoC 12 to transition to the signaled power state. In some embodiments, the power manager 28 may be configured to control the amount of power provided to the components of the SoC 12. For example, the power manager 28 may be configured to control the connection between the components of the SoC 12 and a power rail (not shown). As another example, the power manager 28 may be configured to control the amount of power on the power rail connected to the components of the SoC 12.

[0045] The clock controller 30 may be configured to control the clock signals sent to the components of the SoC 12. In some embodiments, the clock controller 30 may be configured to signal a clock state (such as gated or non-gated) to the components of the SoC 12 to prompt the components of the SoC 12 to transition to the clock state. For example, the components of the SoC 12 may transition to the gated clock state in response to receiving a gated clock state signal from the clock controller 30 by disconnecting from the clock signal, and may transition to the non-gated clock state in response to receiving a non-gated clock state signal from the clock controller 30 by connecting to the clock signal. In some embodiments, the clock controller 30 may be configured to control the clock signals to the components of the SoC 12. For example, the clock controller 30 may disconnect the components of the SoC 12 from the clock signal to transition the components of the SoC 12 to the gated clock state, and may connect the components of the SoC 12 to the clock signal to transition the components of the SoC 12 to the non-gated clock state.

[0046] The processor interface 40 may enable components of the SoC 12, such as the processor 14 and / or memory, to communicate with the processor 40. The processor interface 38 may provide and manage physical and logical connections between components of the SoC 12 and the processor 40. The processor interface 38 may also manage communications between components of the SoC 12 and the processor 40, such as by directing and / or allowing communications between transmitter and receiver pairs of components of the SoC 12 and the processor 40 to communicate. These communications may include the transmission of memory access commands, addresses, data, interrupt signals, status signals, notification signals, etc.

[0047] Interconnect 32 may be a communication structure, such as a communication bus, configured to communicatively connect components of SoC 12. Interconnect 32 may transmit signals between components of SoC 12. In some embodiments, interconnect 32 may be configured to control signals between components of SoC 12 by controlling the timing and / or transmission paths of the signals.

[0048] Some or all of the components of computing device 10 and / or SoC 12 may be arranged and / or combined differently while still serving the functionality of various embodiments. Computing device 10 may not be limited to one of each component, and multiple instances of each component may be included in various configurations of computing devices.

[0049] Figure 2 An example multi-operating system (OS) architecture 200 in a vehicle context suitable for implementing various embodiments is illustrated. Figure 1 and Figure 2, the multi-OS architecture 200 can implement multiple applications for use in a vehicle on a host OS and multiple virtualized guest OSs. For example, an application for generating, receiving, and / or outputting information using multiple visual display devices 202, 204, 206, 208, 210, 212, audio output devices 214 (e.g., speakers), and / or sensors 216 inside and / or outside the vehicle can be implemented on the host OS and multiple guest OSs.

[0050] Applications for the primary visual display may be implemented on the host OS, such as key driving information presented to the driver of the vehicle via the driver dashboard display 202. Other applications may be implemented on multiple guest OSes that are less critical than the primary visual display or have less central functionality to the operation of the vehicle than the primary visual display. Other applications for implementing functions using visual displays implemented on multiple guest OSes may include applications for assisted driving information (e.g., navigation information, driving safety information), communication information (e.g., cellular phone communication information), vehicle system information and control (e.g., vehicle system notifications, heating, ventilation and air conditioning (HVAC) system control, infotainment system control, comfort system control, environmental system control, driving mode system control, etc.). Generation, display, and control of assisted driving information, communication information, vehicle system information and control, etc. may be implemented on the guest OS and displayed via the center display 204, the front passenger display 206, the rearview mirror display 208, the augmented reality and / or head-up display 210, the rear passenger display 212, etc.

[0051] Applications for implementing functions using the audio display 206 may be implemented on multiple guest OSes. Applications for implementing functions using the audio display 206 may include applications for assisting driving information (e.g., navigation information, driving safety information), communication information (e.g., cellular phone communication information), vehicle system information and control (e.g., vehicle system notifications, voice commands for HVAC system control, infotainment system control, comfort system control, environmental system control, driving mode system control, etc.), audio entertainment, noise cancellation, etc. The audio display 214 may include speakers and / or microphones inside and / or outside the vehicle.

[0052] Applications for implementing functions using sensors 216 may be on multiple client OSs. Applications for implementing functions using sensors 216 may include applications for assisted driving information (e.g., navigation information, driving safety information), communication information (e.g., vehicle-to-X (V2X) communication), vehicle system information and control (e.g., HVAC system control, infotainment system control, comfort system control, environmental system control, adaptive driving system control, autonomous driving control, etc.), etc. Sensors 216 may include electromagnetic radiation (e.g., visible light, infrared light, radio waves, lasers, etc.) emitters and / or detectors inside and / or outside the vehicle, pressure sensors, etc.

[0053] Figure 3 An example remote procedure call (RPC) virtualization system 300 suitable for implementing a multi-OS architecture of various embodiments is illustrated. Figures 1 to 3 , the RPC virtualization system 300 may include any number and combination of virtualized client OS 302a, 302b, a hypervisor 308, a host OS 312, system hardware 316, and any number and combination of DSPs 322a, 322b, 322c (e.g., processor 40) (e.g., audio DSP (ADSP) 322a, computing DSP (CDSP) 322b, sensor DSP (SDSP) 322c). The virtualized client OS 302a, 302b, the hypervisor 308, and / or the host OS 312 may be implemented by a processor (not shown) (e.g., processor 14) (such as a CPU).

[0054] The guest OS 302a, 302b may each implement any number and combination of applications 304a, 304b, 304c, 304d. For example, each application 304a-304d may implement a different function for the system (e.g., multi-OS architecture 200). Such functions may include: system information collection, generation, display, storage, analysis, security; system control generation, implementation, security, etc.

[0055] The RPC virtualization system 300 can enable the client OS 302a, 302b and the application 304a-304d to offload the work for implementing functions to any number and combination of DSPs 322a-322c via virtualized RPC. To implement the functions of the application 304a-304d, the client OS 302a, 302b can each implement a client RPC module 306a, 306b. The application 304a-304d can transmit an RPC request for implementing the function by one or more of the DSPs 322a-322c to the client RPC module 306a, 306b implemented on the same client OS 302a, 302b. The client RPC module 306a, 306b can virtualize the RPC request to generate a virtual RPC request. RPC request virtualization by the guest RPC modules 306a, 306b may include storing the RPC request information in a shared memory 318 (e.g., memory 16, 36) of the hardware 316. Each guest OS 302a, 302b may be associated with a specific virtual queue in the shared memory 318 for storing RPC request information from the guest OS 302a, 302b. RPC request virtualization by the guest RPC modules 306a, 306b may also include transmitting notification of the RPC request to the host OS 312 via the hypervisor 308.

[0056] In response to receiving the notification of the RPC request, the hypervisor 308 may generate an interrupt 310a, 310b and transmit it to the host OS 312. The interrupt 310a, 310b may be configured to trigger the host OS 312 to respond to the RPC request. Each interrupt 310a, 310b may be configured for a specific guest OS 302a, 302b. A host RPC module 314 may be implemented by the host OS 312 to process the interrupts 310a, 310b and the RPC request. In response to receiving the interrupt 310a, 310b, the host RPC module 314 may generate an RPC request based on the information of the virtual RPC request stored at the shared memory 318 and transmit it to one or more of the DSPs 322a-322c. For example, a host RPC module 314 responding to an interrupt 310a, 310b for a particular guest OS 302a, 302b may retrieve information of a virtual RPC request from a virtual queue of the particular guest OS 302a, 302b at the shared memory 318.

[0057] In response to receiving an RPC request from the host RPC module 314, the DSP 322a-322c may implement the work of the RPC request. The DSP 322a-322c may implement the work based on information of the received RPC request and / or information retrieved from the shared memory 318. For example, the DSP 322a-322c implementing the work of the RPC request may retrieve the information of the RPC request from the virtual queue of the particular guest OS 302a, 302b associated with the RPC request at the shared memory 318.

[0058] The DSPs 322a-322c may store the results of the work to transmit an RPC result message to the host OS 312. In response to receiving the RPC result message at the host OS 312, the host RPC module 314 may generate a virtual RPC result message and transmit it to the guest OS 302a, 302b via the hypervisor 308. Generating the virtual RPC result message may include storing the RPC result message information to the shared memory 318. For example, the host RPC module 314 may store the RPC result message information to a virtual queue of the guest OS 302a, 302b in the shared memory 318 for which the RPC result notification is intended.

[0059] In response to receiving the virtual RPC result message, the hypervisor 308 may generate an interrupt 310a, 310b and transmit it to the guest OS 302a, 302b. The interrupt 310a, 310b may be configured to trigger the guest OS 302a, 302b to respond to the RPC result message. Each interrupt 310a, 310b may be configured for a specific guest OS 302a, 302b. The guest RPC module 306a, 306b implemented by the guest OS 302a, 302b may be configured to process the interrupt 310a, 310b and the RPC result message. In response to receiving the interrupt 310a, 310b, the guest RPC module 306a, 306b may generate an RPC result message based on the information of the virtual RPC result message stored at the shared memory 318 and transmit it to one or more of the applications 304a-304d. For example, a guest RPC module 306a, 306b responsive to an interrupt 310a, 310b for a particular guest OS 302a, 302b may retrieve information of a virtual RPC result message from a virtual queue of the particular guest OS 302a, 302b at the shared memory 318.

[0060] Figure 4A An RPC virtualization system 400 (eg, RPC virtualization system 300 ) suitable for implementing various embodiments is illustrated. Figure 4B A method 450 for RPC virtualization according to some embodiments is illustrated. Figures 1 to 4B, the RPC virtualization system 400 may include an application 402 (e.g., applications 304a-304d), a client RPC module 404 (e.g., client RPC modules 306a, 306b), a hypervisor 412 (e.g., hypervisor 308), a host RPC module 416 (e.g., host RPC module 314), and hardware 424 (e.g., hardware 316). The method 450 may be implemented using any combination of the client RPC module 404, the hypervisor 412, the host RPC module 416, and / or the hardware 424.

[0061] The client RPC module 404 may include an RPC user space 406, a front-end RPC module 408, and a virtualization framework 410 (e.g., Virtio). The RPC user space 406 may provide an API to the application 402. These APIs may be configured to enable the application 402 to execute on a single OS and / or client OS (e.g., client OS 302a, 302b) without modification. The application 402 may directly call the RPC user space 406. The application 402 may control parameters for the RPC request, such as the buffer type and application process attributes used to implement the RPC request.

[0062] In response to the RPC request made by the application 402, the RPC user space 406 can make an RPC request of the front-end RPC module 408. The front-end RPC module 408 can package the RPC request message and transmit the RPC request message to the back-end RPC module 420 via the virtualization framework 410. The front-end RPC module 408 can be configured to handle complex AI modules of different demand types, multiple applications 402 and / or client OS. The method 450 may include receiving a first plurality of RPC requests from multiple RPC sources (e.g., applications 402) executed concurrently by at least one first virtual RPC module (e.g., the front-end RPC module 408) in box 452 by at least one GVM in a plurality of GVMs. In some embodiments, the first plurality of RPC requests may be received concurrently. In some embodiments, the first plurality of RPC requests may include a first RPC request from a first RPC source in a plurality of RPC sources and a second RPC request from a second RPC source in a plurality of RPC sources, wherein the first RPC request and the second RPC request may be directed to a second processor of the computing device.

[0063] To package the RPC request message, the front-end RPC module 408 may check the buffer type and application process attributes for the RPC request. The front-end RPC module 408 may support buffers with offsets, overlapping buffers, and persistent buffers. Variable buffer support may increase application performance and consider a greater number of scenarios than when the system lacks variable buffer support. The method 450 may include generating a plurality of RPC request messages from the first plurality of RPC requests by at least one first virtual RPC module (e.g., the front-end RPC module 408) in block 454.

[0064] In some embodiments, the first plurality of RPC requests may include a first RPC request and a second RPC request from a first RPC source in the plurality of RPC sources, wherein the first RPC request may be directed to a second processor of the computing device, and the second RPC request may be directed to a third processor of the computing device. In such embodiments, generating a second plurality of RPC requests for the plurality of RPC request messages in block 454 may include generating a third RPC request directed to the second processor and a fourth RPC request directed to the third processor.

[0065] In some embodiments, the plurality of RPC sources may include a first application and a second application, and the first plurality of RPC requests may include a first RPC request from the first application and a second RPC request from the second application. In such embodiments, generating a second plurality of RPC requests for the plurality of RPC request messages may include generating a third RPC request directed to the second processor and a fourth RPC request directed to the second processor.

[0066] In some embodiments, the plurality of RPC sources may include a first application and a second application, and the first plurality of RPC requests may include a first RPC request from the first application and a second RPC request from the second application, and generating a second plurality of RPC requests for the plurality of RPC request messages in block 454 may include generating a third RPC request from the first application and generating a fourth RPC request from the second application. Such embodiments may also include pushing the third RPC request to a first thread pool for the first application and pushing the fourth RPC request to a second thread pool for the second application.

[0067] To transmit the packaged RPC request message, the front-end RPC module 408 may store the process attributes and the requested DSP for each application 408, and transmit the information to the back-end RPC module 420 during the open request. The front-end RPC module 408 may create a send and receive virtual queue (e.g., Virtio virtqueue) for the associated guest OS in the shared memory 426 (e.g., memory 16, 36, shared memory 318) of the hardware 424. The front-end RPC module 408 may store the information of the packaged RPC request message to the send virtual queue. The front-end RPC module 408 may transmit an RPC request notification to notify the back-end RPC module 420 of the packaged RPC request message. The method 450 may include transmitting the plurality of RPC request messages from at least one first virtual RPC module (e.g., the front-end RPC module 408) to a memory (e.g., the shared memory 426) of the computing device (e.g., the computing device 10) in block 456.

[0068] The hypervisor 412 may enable communication between the front-end RPC module 408 and the back-end RPC module 420. The hypervisor 412 may receive the RPC request notification and may generate a guest OS-specific interrupt 414 for transmission to the back-end RPC module 420.

[0069] The host RPC module 416 may include a virtualization framework 418 (e.g., Virtio), a backend RPC module 420, and an RPC driver 422. The backend RPC module 420 may receive a packaged RPC request message from the frontend RPC module 408. In response to receiving the interrupt 414, the backend RPC module 420 may retrieve the packaged RPC request message and unpack it. The backend RPC module 420 may retrieve information of the packaged RPC request message from the send virtual queue in the shared memory 426 via the virtualization framework 418. The backend RPC module 420 may retrieve application process attributes and the requested DSP, check different buffer types for transient buffers and / or persistent buffers, overlapping buffers, buffers with offsets, etc. The use of application process attributes and variable buffer types may enable multiple applications 402 and guest OSs to execute concurrently, and enable RPC requests for applications 402 to be implemented for multiple DSPs (not shown) (e.g., processor 40, DSP 322a-322c). The method 450 may include, in block 458 , retrieving, by a second virtual RPC module (eg, backend RPC module 420 ) executed by a first processor (eg, processor 14 ) a plurality of RPC request messages from a memory (eg, shared memory 426 ).

[0070] In some embodiments, at least one GVM may include a first GVM and a second GVM, a plurality of RPC sources may include the first GVM and the second GVM, and a first plurality of RPC requests may include a first RPC request from the first GVM and a second RPC request from the second GVM. In such embodiments, generating a plurality of RPC request messages from the first plurality of RPC requests in box 454 may include generating a first RPC request message from the first RPC request and generating a second RPC request message from the second RPC request. In such embodiments, transmitting a plurality of RPC request messages from at least one first virtual RPC module to a memory in box 456 may include pushing the first RPC request message to a first queue for the first GVM and pushing the second RPC request message to a second queue for the second GVM. In addition, in such embodiments, retrieving a plurality of RPC request messages from the memory by the second virtual RPC module in box 458 may include retrieving a first RPC request message from a first queue for the first GVM and retrieving a second RPC request message from a second queue for the second GVM.

[0071] In some embodiments, at least one GVM may include a first GVM and a second GVM, a plurality of RPC sources may include the first GVM and the second GVM, a first plurality of RPC requests may include a first RPC request from the first GVM and a second RPC request from the second GVM, and at least one first virtual RPC module may include a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM. In such embodiments, generating a plurality of RPC request messages from the first plurality of RPC requests in block 454 may include generating a first RPC request message from the first RPC request by the first virtual RPC module executed by the first GVM, and generating a second RPC request message from the second RPC request by the first virtual RPC module executed by the second GVM. In such embodiments, transmitting a plurality of RPC request messages from the at least one first virtual RPC module to a memory in block 456 may include transmitting a first RPC request message to a memory by the first virtual RPC module executed by the first GVM, and transmitting a second RPC request message to a memory by the first virtual RPC module executed by the second GVM. Such embodiments may further include: transmitting a first RPC request notification for the first GVM from a first virtual RPC module executed by the first GVM to a second virtual RPC module; and transmitting a second RPC request notification for the second GVM from the first virtual RPC module executed by the second GVM to the second virtual RPC module. In such embodiments, retrieving the plurality of RPC request messages from the memory by the second virtual RPC module in block 458 may include retrieving the first RPC request message from the memory in response to receiving the first RPC request notification, and retrieving the second RPC request message from the memory in response to receiving the second RPC request notification.

[0072] The method 450 may include generating, by a second virtual RPC module (e.g., the backend RPC module 420), a second plurality of RPC requests for the plurality of RPC request messages in block 460. The backend RPC module 420 may transmit the unpacked RPC request message along with the information retrieved from the shared memory 426 to the RPC driver 422.

[0073] In some embodiments, generating the plurality of RPC request messages from the first plurality of RPC requests in block 454 may include generating the plurality of RPC request messages using data of the plurality of RPC request messages from a first buffer and a buffer attribute of the first buffer. In such embodiments, generating the second plurality of RPC requests from the plurality of RPC request messages in block 460 may include: mapping a second buffer using the buffer attribute; storing the data of the plurality of RPC request messages to the second buffer; and generating the second plurality of RPC requests using data of the plurality of RPC request messages from the second buffer.

[0074] In some embodiments, an application may specify that a persistent buffer is used for an RPC request of the application. For such embodiments, a first persistent buffer and a second persistent buffer may be mapped for use by the application. In box 454, using data from a plurality of RPC request messages of the first buffer to generate a plurality of RPC request messages may include using at least one file descriptor for data of at least one RPC request message to generate at least one RPC request message for at least one RPC request of the application. In such embodiments, in box 458, at least one file descriptor may be used to retrieve data of at least one RPC request message from at least one RPC request message of the first persistent buffer, and the data of at least one RPC request message may be stored in a second persistent buffer. In box 460, generating a second plurality of RPC requests from a plurality of RPC request messages may include using data of at least one RPC request message from the second persistent buffer to generate at least one RPC request in the second plurality of RPC requests. The specified persistent buffer may be used to specify any application that uses a persistent buffer for an RPC request of an application. The persistent buffer may be mapped across a plurality of RPC requests for specifying an application that uses a persistent buffer. Other applications that do not specify the use of a persistent buffer may use other components (such as other buffers) to generate and retrieve RPC request messages.

[0075] Some embodiments of the method may further include setting a process attribute of the plurality of RPC sources, wherein generating the plurality of RPC request messages from the first plurality of RPC requests in block 454 may include generating the plurality of RPC request messages from the first plurality of RPC requests based on the process attribute. Such embodiments may further include using the process attribute from the plurality of RPC request messages to set a process attribute for implementing a second plurality of RPC requests.

[0076] In response to receiving the unpacked RPC request message, the RPC driver 422 may transmit the unpacked RPC request message to the DSP via the shared memory 426. The RPC driver 422 may construct the RPC request message according to the protocol with the DSP, and communicate the RPC request message with the DSP via the shared memory 426. The RPC driver 422 may create a thread pool for each application process and push the RPC request message to the associated thread pool. The DSP may implement the work of the RPC request message and provide the RPC result to the RPC driver 422. In response to receiving the RPC result, the RPC driver 422 may forward the RPC result to the backend RPC module 420. The method 450 may include receiving (e.g., by the backend RPC module 420) a first plurality of RPC results for a second plurality of RPC requests in block 462.

[0077] In response to receiving the RPC result, the backend RPC module 420 may transmit an RPC return message or an RPC result message to the frontend RPC module 408 via a receive virtual queue. In the process of transmitting the RPC return message, the backend RPC module 402 may check and remove unused persistent buffers in the shared memory 426, retrieve more data from the DSP (such as file descriptors and error detection codes (e.g., cyclic redundancy check (CRC)) for persistent data), and package the RPC return message. The backend RPC module 420 may push the packaged RPC return message to the receive virtual queue for the target guest OS and transmit the RPC return notification to the frontend RPC module 408. The hypervisor 412 that implements communication between the backend RPC module 420 and the frontend RPC module 408 may generate an interrupt 414 specific to the guest OS in response to the RPC return notification for transmission to the frontend RPC module 408. The method 450 may include generating (e.g., by the backend RPC module 420) a plurality of RPC result messages from the first plurality of RPC results in block 464. The method 450 may include, at block 466 , transmitting the plurality of RPC result messages from the second virtual RPC module (eg, the backend RPC module 420 ) to a memory (eg, the shared memory 426 ).

[0078] In response to the front-end RPC module 408 receiving the interrupt 414, the front-end RPC module 408 may retrieve and unpack the RPC return message from the receive virtual queue. The front-end RPC module 408 may transmit the RPC return message to the RPC user space 406. The front-end RPC module 408 may process unused persistent buffers for the RPC return message and other aspects of the RPC return message, such as extended functions like cyclic redundancy check (CRC) checks, file configuration data, etc., and copy the RPC result from the receive virtual queue to the RPC user space 406. The method 450 may include retrieving a plurality of RPC result messages from a memory (e.g., the shared memory 426) by at least one first virtual RPC module (e.g., the front-end RPC module 408) in block 468. The method 450 may include transmitting the plurality of RPC result messages from the at least one first virtual RPC module (e.g., the front-end RPC module 408) to a plurality of RPC sources (e.g., the application 402) in block 470.

[0079] In some embodiments, at least one GVM may include a first GVM and a second GVM, a plurality of RPC sources may include the first GVM and the second GVM, a first plurality of RPC results may include a first RPC result for the first GVM and a second RPC result for the second GVM, and at least one first virtual RPC module may include a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM. In such embodiments, generating a plurality of RPC result messages from the first plurality of RPC results in box 454 may include generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result. In such embodiments, transmitting the plurality of RPC result messages from the second virtual RPC module to the memory in box 466 may include pushing the first RPC result message to a first queue of the first GVM and pushing the second RPC result message to a second queue of the second GVM. In such an embodiment, retrieving multiple RPC result messages from the memory by at least one first virtual RPC module in box 468 may include retrieving a first RPC result message from a first queue of the first GVM by the first virtual RPC module executed by the first GVM, and retrieving a second RPC result message from a second queue of the second GVM by the first virtual RPC module executed by the second GVM.

[0080] In some embodiments, at least one GVM may include a first GVM and a second GVM, and a plurality of RPC sources may include the first GVM and the second GVM, at least one first virtual RPC module may include a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, and a first plurality of RPC results may include a first RPC result for the first GVM and a second RPC result for the second GVM. In such embodiments, generating a plurality of RPC result messages from the first plurality of RPC results in block 454 may include generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result. In such embodiments, transmitting a plurality of RPC result messages from the second virtual RPC module to a memory in block 466 may include transmitting a first RPC result message and a second RPC result message to a memory. In such embodiments, the method further includes transmitting a first RPC result notification for the first GVM from the second virtual RPC module to the first virtual RPC module executed by the first GVM; and transmitting a second RPC result notification for the second GVM from the second virtual RPC module to the first virtual RPC module executed by the second GVM. In such an embodiment, retrieving multiple RPC result messages from the memory by at least one first virtual RPC module in box 468 may include retrieving a first RPC result message from the memory by the first virtual RPC module executed by the first GVM in response to receiving a first RPC result notification; and retrieving a second RPC result message from the memory by the first virtual RPC module executed by the second GVM in response to receiving a second RPC result notification.

[0081] For applications that specify the use of a persistent buffer, the persistent buffer may also be used to return the RPC result to the application. In some embodiments, generating multiple RPC result messages from the first plurality of RPC results in box 464 may include: for an RPC request from the application, using at least one file descriptor for the first RPC result from the first persistent buffer to generate the first RPC result message. In such embodiments, retrieving multiple RPC result messages from memory by at least one first virtual RPC module in box 468 may include retrieving at least one file descriptor for the first RPC result from a second persistent buffer. Such an embodiment method may also include releasing the first persistent buffer storing at least one file descriptor for the first plurality of RPC results, and releasing the second persistent buffer storing at least one file descriptor for the first RPC result.

[0082] In some embodiments, the plurality of RPC sources may include one or more of: a plurality of client virtual machines, a plurality of applications running on the client virtual machines, or at least one application running on each of the plurality of client virtual machines.

[0083] The examples described herein provide hypervisor and Virtio based communications for RPC virtualization communications between the guest RPC module 404 and the host RPC module 416. The described examples are not exhaustive and non-limiting, and those skilled in the art will recognize that the hypervisor and Virtio based communications may be replaced with other components for different systems.

[0084] Figure 5 is a message flow diagram illustrating an RPC virtualization system 500 (eg, RPC virtualization systems 300, 400) suitable for implementing various embodiments. Figures 1 to 5 , the RPC virtualization system 500 may include an application 402, an RPC user space 406, a front-end RPC module 408, a hypervisor 412, a back-end RPC module 420, an RPC driver 422, a shared memory 426, and a DSP 502 (eg, processor 40, DSP 322a, 322b, 322c).

[0085] The application 402 may generate and transmit an RPC request 504. Multiple applications 402 on one or more GVMs (not shown) (e.g., guest OS 302a, 302b) may generate and transmit RPC requests concurrently. Multiple RPC requests may be directed to any number and combination of DSPs 502 concurrently. For example, multiple RPC requests may be directed to the same DSP 502 concurrently and / or to different DSPs 502 concurrently. The persistent buffer in the shared memory 426 may be shared across multiple RPC requests. The RPC request may be configured to enable requests for session attribute settings, offloading non-signed objects to a limited area of ​​the DSP 502, unsigned settings, asynchronous communication between the CPU (not shown) (e.g., processor 14) and the DSP 502, error code checks (e.g., CRC checks) on buffers, file configuration data, and the like.

[0086] The RPC user space 406 may receive the RPC request and may generate and transmit an input / output control (Ioctl) command 506. The Ioctl command may be configured to enable commands and parameters for RPC requests with application process attributes and using a persistent buffer.

[0087] In operation 508, the front-end RPC module 408 may receive the Ioctl command and package the RPC request message. To package the RPC request message 508, the front-end RPC module 408 may copy the buffer data for the application 402 or find the buffer data for the application 402 via the file descriptor, and check the buffer overlap, buffer offset, and reconstruction format. The front-end RPC module 408 may also set the process attributes of the application 402, package the buffer data, buffer attributes, file descriptors, and reserve space in the shared memory 426 for asynchronous data, error checking data, and other data.

[0088] In operation 510 , the front-end RPC module 408 may push the RPC request message to the virtual send queue. The front-end RPC module 408 may push the RPC request message to the virtual send queue 510 for the associated GVM in the shared memory 426 .

[0089] The front-end RPC module 408 may generate and transmit an RPC request notification 512. The RPC request notification may be configured to notify the back-end RPC module 420 of receiving the RPC request message. The RPC request notification may include an interrupt associated with the GVM from which the RPC request originated. In some embodiments, the hypervisor 412 may enable the transmission of the RPC request notification 512. For example, the hypervisor 412 may receive the RPC request notification and generate an interrupt for the associated GVM and transmit it to the back-end RPC module 420.

[0090] The backend RPC module 420 may receive an RPC request notification and retrieve an RPC request message from a send virtual queue in the shared memory 426 in operation 514. In some embodiments, the RPC request notification may include receiving an interrupt transmitted by the hypervisor 412 in response to the RPC request notification. The backend RPC module 420 may identify a send virtual queue associated with a GVM, retrieve an RPC request message from the GVM that is identical to the GVM associated with the received RPC request notification and / or interrupt. When retrieving the RPC request message, the backend RPC module 420 may check and set process attributes, check buffer types, reconstruct formats, overlap buffers, map buffers with the same attributes as the frontend RPC module 408, and process buffer offsets. For persistent buffer types, the backend RPC module 420 may retrieve data for the buffer via a file descriptor and maintain a mapping of the persistent buffer across RPCs.

[0091] In operation 516, the backend RPC module 420 may push an RPC request for the retrieved RPC request message to a thread pool for the GVM and / or application 402 from which the RPC request originated. The backend RPC module 420 may initiate a thread pool for each GVM and / or application 402 and push the RPC request to a thread pool associated with the same GVM and / or application as the RPC request.

[0092] Backend RPC module 420 may release the send virtual queue in shared memory 426 in response to retrieving the data from the send virtual queue in communication 517. In response to backend RPC module 420 using the data, the data from the send virtual queue may be free to open space for subsequent RPC requests.

[0093] The backend RPC module 420 may generate and transmit an RPC request 518, which may be received by the RPC driver 422. The RPC request generated by the backend RPC module 420 may represent an RPC request generated by the application 402 based on the use of the RPC request information pushed to the send queue by the frontend RPC module 408 and retrieved from the send queue by the backend RPC module 420. Therefore, the RPC driver 422 may be unaware of the virtualization of the RPC request and may process the RPC request as if it were received from the application 402. The RPC driver 422 may generate and transmit an RPC request message 520.

[0094] DSP 502 receives the RPC request message from RPC driver 422, performs the work of the RPC request message, and stores the result of the work to shared memory 426. DSP 502 may generate and transmit RPC result 522, which may be received by RPC driver 422. RPC driver 422 may generate and transmit RPC result message 524.

[0095] In operation 526, the backend RPC module 420 may receive the RPC result message and copy the data of the RPC result message from the buffer in the shared memory 426. The data of the RPC result message may include a file descriptor, error checking data, and other data. In operation 528, the backend RPC module 420 may check and release the buffer in the shared memory 426. For example, the backend RPC module 420 may copy data from a persistent buffer used across RPC requests. The backend RPC module 420 may copy the data to the RPC result message. In operation 529, the backend RPC module 420 may push the RPC result message to a receive virtual queue in the shared memory 426. The receive virtual queue may be associated with the GVM from which the RPC request originated.

[0096] The backend RPC module 420 may generate and transmit an RPC result notification 530. The RPC result notification may be configured to notify the frontend RPC module 408 of receiving the RPC result message. The frontend RPC module 408 may receive the RPC result notification and may respond to the RPC result notification by transmitting a receipt confirmation 532. The receipt confirmation may include an interrupt associated with the GVM from which the RPC request originated. In some embodiments, the hypervisor 412 may enable the transmission of the receipt confirmation 532. For example, the hypervisor 412 may receive the receipt confirmation and generate an interrupt for the associated GVM and transmit it to the frontend RPC module 408.

[0097] The front-end RPC module 408 may retrieve an RPC result message from a receive virtual queue in the shared memory 426 in operation 534. The front-end RPC module 408 may identify a receive virtual queue associated with a GVM from which to retrieve an RPC result message identical to the GVM from which the RPC originated. When retrieving the RPC result message, in operation 526, the front-end RPC module 408 may examine and copy the data of the RPC result message from the buffer in the shared memory 426. The data of the RPC result message may include a file descriptor, error checking data, file configuration data, and other data. The front-end RPC module 408 may transmit the RPC result message 536 to the application 402 via the RPC user space 406, which forwards the RPC result message 536.

[0098] According to various embodiments (including but not limited to the above reference Figures 1 to 5 The system of the described embodiments) can be implemented in a variety of computing systems including mobile computing devices, an example of which is suitable for use with various embodiments is Figure 6. The mobile computing device 600 may include a processor 602 coupled to a touch screen controller 604 and an internal memory 606. The processor 602 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 606 may be volatile or non-volatile memory, and may also be secure and / or encrypted memory, or unsecure and / or unencrypted memory, or any combination thereof. Examples of available memory types include, but are not limited to, DDR, low power DDR (LPDDR), graphic DDR (GDDR), WIDEIO, RAM, static RAM (SRAM), dynamic RAM (DRAM), parameter RAM (P-RAM), resistive RAM (R-RAM), magnetoresistive RAM (M-RAM), spin transfer torque RAM (STT-RAM), and embedded DRAM. The touch screen controller 604 and the processor 602 may also be coupled to a touch screen panel 612, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, etc. Additionally, the display of the mobile computing device 600 does not need to have touch screen capabilities.

[0099] The mobile computing device 600 may have one or more radio signal transceivers 608 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radios) and antennas 610 coupled to each other and / or to the processor 602 for transmitting and receiving communications. The transceiver 608 and antenna 610 may be used with the circuits mentioned above to implement various wireless transmission protocol stacks and interfaces. The mobile computing device 600 may include a cellular network wireless modem chip 616 that enables communication via a cellular network and is coupled to the processor.

[0100] The mobile computing device 600 may include a peripheral device connection interface 618 coupled to the processor 602. The peripheral device connection interface 618 may be configured solely to accept one type of connection, or may be configured to accept various types of physical and communication connections that are shared or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 618 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0101] The mobile computing device 600 may also include a speaker 614 for providing audio output. The mobile computing device 600 may also include a housing 620 for housing all or some of the components described herein, the housing being constructed of plastic, metal, or a combination of materials. The mobile computing device 600 may include a power source 622 coupled to the processor 602, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive a charging current from a source external to the mobile computing device 600. The mobile computing device 600 may also include a physical button 624 for receiving user input. The mobile computing device 600 may also include a power button 626 for turning the mobile computing device 600 on and off.

[0102] According to various embodiments (including but not limited to the above reference Figures 1 to 5 The system of the described embodiments) can be implemented in a variety of computing systems including a laptop computer 700, an example of which is shown in FIG. Figure 7 . Many laptop computers include a touchpad touch surface 717 that serves as a pointing device for the computer and can therefore receive drag, scroll, and tap gestures similar to those implemented on computing devices equipped with a touch screen display and as described above. Laptop computer 700 will typically include a processor 702 coupled to volatile memory 712 and a disk drive 713 of a large capacity non-volatile memory such as flash memory. Additionally, computer 700 may have one or more antennas 708 for transmitting and receiving electromagnetic radiation that may be connected to a wireless data link and / or a cellular telephone transceiver 716 coupled to processor 702. Computer 700 may also include a floppy disk drive 714 and a compact disk (CD) drive 715 coupled to processor 702. In a notebook configuration, the computer housing includes a touchpad 717, a keyboard 718, and a display 719, all coupled to processor 702. Other configurations of computing devices may include a computer mouse or trackball coupled to a processor (e.g., via a USB input) as is well known, which may also be used in conjunction with various embodiments.

[0103] According to various embodiments (including but not limited to the above reference Figures 1 to 5 The system of the described embodiment) can also be implemented in a fixed computing system, such as any of a variety of commercially available servers. Figure 8 An example server 800 is illustrated in FIG. Such a server 800 typically includes one or more multi-core processor assemblies 801 coupled to a volatile memory 802 and a large capacity non-volatile memory (such as a disk drive 804). Figure 8As shown, a multi-core processor assembly 801 can be added to a server 800 by inserting it into a chassis for the assembly. The server 800 may also include a floppy disk drive, a compact disk (CD), or a digital versatile disk (DVD) disk drive 806 coupled to the processor 801. The server 800 may also include a network access port 803 coupled to the multi-core processor assembly 801 for establishing a network interface connection with a network 805, such as a local area network coupled to other broadcast system computers and servers, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, 5G, or any other type of cellular data network).

[0104] According to various embodiments (including but not limited to the above reference Figures 1 to 5 The methods of the embodiments described herein and apparatus for implementing such methods may be implemented in a variety of computing systems including an embedded vehicle computing system 900, an example of which is shown in FIG. 9A to 9C The embedded vehicle computing system 900 may include a vehicle control unit 940 (such as an ECU), which may include a processor, such as a CPU, an AI processor, etc. The embedded vehicle computing system 900 may include a plurality of sensors 942-970, including a satellite geo-positioning system receiver 942, an accelerometer 944, occupancy sensors 946, 948, 950, 952, tire pressure sensors 954, 956, cameras 958, 960, microphones 962, 964, impact sensors 966, radar 968, and lidar 970.

[0105] A plurality of sensors 942-970 disposed in or on a vehicle may be used for various purposes, such as autonomous and semi-autonomous navigation and control, collision avoidance, position determination, etc., and sensor data about objects and people in or on a vehicle. Sensors 942-970 may include one or more sensors of a variety of sensors capable of detecting various information useful for navigation and collision avoidance. Each of the sensors 942-970 may communicate with the control unit 940 and with each other by wire or wireless communication. Specifically, the sensor may include one or more cameras 958, 960 or other optical sensors or photoelectric sensors. The sensor may also include other types of object detection and ranging sensors, such as radar 968, lidar 970, IR sensors, and ultrasonic sensors. Sensors may also include tire pressure sensors 954, 956, humidity sensors, temperature sensors, satellite geolocation sensors 942, control input sensors 945, accelerometers 944, vibration sensors, gyroscopes, gravimeters, impact sensors 966, force gauges, strain gauges, strain sensors, fluid sensors, chemical sensors, gas content analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biomaterial sensors, microphones 962, 964, occupancy sensors 946, 948, 950, 952, proximity sensors, and other sensors.

[0106] The vehicle control unit 940 may include one or more processors configured with processor executable instructions to perform navigation and collision avoidance operations using information received from various sensors (particularly cameras 958, 960). In some embodiments, the control unit 940 may use the distance and relative position (e.g., relative azimuth) obtained from radar 968 and / or laser radar 970 sensors to supplement the processing of camera images. The control unit 940 may also be configured to use information about other vehicles determined using various embodiments to control the steering, braking, and speed of the vehicle when operating in an autonomous or semi-autonomous mode. The vehicle control unit 940 may include one or more processors configured with processor executable instructions to receive information from sensors 942-970 and perform operations using such information, as further described herein. In various embodiments, the vehicle control unit 940 may include a V2X airborne equipment of a vehicle, may be a component of a V2X airborne equipment of a vehicle, or may communicate with a V2X airborne equipment of a vehicle.

[0107] Fig. 9C900 is a component block diagram illustrating an embedded vehicle computing system 900 including components and support systems suitable for implementing various embodiments. The embedded vehicle computing system 900 may include a control unit 940, which may include various circuits and devices for controlling the operation of the vehicle. The control unit 940 may include a processor 940a (such as a CPU, an AI processor, etc.), a memory 940b, an input module 940c, an output module 940d, and a radio module 940e. The control unit 940 may be coupled to a driving control component 972a, a navigation component 972b, and one or more sensors 972c of the embedded vehicle computing system 900, and is configured to control the driving control component, the navigation component, and the one or more sensors. The control unit 940 may communicate with V2X airborne equipment 940f. The processor 940a may be configured with processor executable instructions to control the maneuvering, navigation, and / or other operations of the vehicle, including the operations of various embodiments, including collecting and analyzing real-world autonomous vehicle operation data collected from the sensor 972c. The processor 940a may be coupled to the memory 940b. The V2X onboard equipment 940f may include one or more processors 940g configured with processor-executable instructions to perform various operations of various embodiments, including communicating real-world autonomous vehicle operation data collected from sensors 972c between the embedded vehicle computing system 940 and the wireless communication device 912 and / or a computing device on a communication network (e.g., core network 932) via a radio module 940e.

[0108] The radio module 940e may be configured for wireless communication. The radio module 940e may exchange signals (e.g., command signals for controlling maneuvers, signals from navigational aids, data signals, etc.) with a network transceiver (e.g., base station 910) via a communication link 922, and may provide these signals to the processor 940a, 940g, and / or the navigation unit 972b. In some embodiments, the radio module 940e may enable the embedded vehicle computing system 900 to communicate with the wireless communication device 912 via a wireless communication link 924. The wireless communication link 924 may be a bidirectional or unidirectional communication link, and may use one or more communication protocols.

[0109] Input module 940c can receive sensor data from one or more vehicle sensors 972c and electronic signals from other components, including driving control component 972a and navigation component 972b. Output module 940d can communicate with or activate various components of embedded vehicle computing system 900, including driving control component 972a, navigation component 972b, and sensor 972c.

[0110] The control unit 940 may be coupled to a driving control assembly 972a to control physical elements of the vehicle related to maneuvering and navigation of the vehicle, such as an engine, motor, throttle, steering elements, flight control elements, braking or deceleration elements, etc. The driving control assembly 972a may also include components for controlling other devices of the vehicle, including interior environmental controls (e.g., air conditioning and heating), exterior and / or interior lighting, interior and / or exterior information displays (which may include display screens or other devices for displaying information), safety devices (e.g., tactile devices, audible alarms, etc.), and other similar devices.

[0111] The control unit 940 may be coupled to the navigation component 972b, and may receive data from the navigation component 972b and be configured to use such data to determine the current position and orientation of the vehicle, as well as the appropriate route towards the destination. The navigation component 972b may include or be coupled to a GNSS receiver system (e.g., one or more global positioning system (GPS) receivers) that enables the embedded vehicle computing system 900 to use a global navigation satellite system (GNSS) signal to determine its current position. Alternatively or in addition, the navigation component 972b may include a radio navigation receiver for receiving navigation beacons or other signals from a radio node (such as a Wi-Fi access point, a cellular network site, a radio station, a remote computing device, other vehicles, etc.). By controlling the driving control element 972a, the processor 940a can control vehicle navigation and maneuvers. The processors 940a, 940g and / or the navigation component 972b may be configured to communicate with a network element, such as a server in a communication network (e.g., the core network 932), via wireless communication links 922, 926 to receive commands for controlling maneuvers, receive data useful in navigation, provide real-time position reports, etc.

[0112] The control unit 940 may be coupled to one or more sensors 972c. The sensors 972c may include sensors 942-970 as described, and may be configured to provide various data to the processors 940a, 940g.

[0113] Although the control unit 940 is described as including separate components, in some embodiments, some or all of the components (e.g., the processor 940a, the memory 940b, the input module 940c, the output module 940d, and the radio module 940e) may be integrated into a single device or module (such as a SoC processing device). Such a SoC processing device may be configured for use in a vehicle and configured, such as with processor-executable instructions executed in the processor 940a to perform navigation and collision avoidance operations.

[0114] Specific implementation examples are described in the following paragraphs. Although some of the specific implementation examples below are described in terms of example systems, devices, or methods, other example implementations may include: example systems or devices discussed in the following paragraphs implemented as methods for performing the operations of the example systems or devices, example systems, devices, or methods discussed in the following paragraphs implemented by a computing device including a processing device configured with processing device executable instructions to perform the operations of the example systems, devices, or methods; computing devices including components for performing the functions of the example systems, devices, or methods; and example systems, devices, or methods discussed in the following paragraphs implemented as non-transitory processor-readable storage media having processor-executable instructions stored thereon, which are configured to cause a processor of a computing device to perform the operations of the example systems, devices, or methods.

[0115] Embodiment 1. A method for implementing a remote procedure call (RPC) executed in a first processor of a computing device, wherein the first processor is configured to execute multiple client virtual machines (GVMs) in parallel, the method comprising: receiving a first plurality of RPC requests from multiple RPC sources concurrently executed by the at least one GVM through at least one first virtual RPC module executed by at least one of the multiple GVMs; generating a plurality of RPC request messages from the first plurality of RPC requests through the at least one first virtual RPC module; transmitting the plurality of RPC request messages from the at least one first virtual RPC module to a memory of the computing device; retrieving the plurality of RPC request messages from the memory through a second virtual RPC module executed by the first processor; and generating a second plurality of RPC requests for the plurality of RPC request messages through the second virtual RPC module.

[0116] Embodiment 2. A method according to embodiment 1, wherein receiving the first plurality of RPC requests includes receiving the first plurality of RPC requests concurrently.

[0117] Embodiment 3. A method according to any one of Embodiments 1 or 2, wherein the first plurality of RPC requests includes a first RPC request and a second RPC request from a first RPC source among the multiple RPC sources, the first RPC request is directed to a second processor of the computing device and the second RPC request is directed to a third processor of the computing device, and generating the second plurality of RPC requests for the multiple RPC request messages includes generating a third RPC request directed to the second processor and a fourth RPC request directed to the third processor.

[0118] Embodiment 4. A method according to any one of Embodiments 1 or 2, wherein the first plurality of RPC requests includes a first RPC request from a first RPC source among the multiple RPC sources and a second RPC request from a second RPC source among the multiple RPC sources, the first RPC request and the second RPC request are directed to a second processor of the computing device, and generating the second plurality of RPC requests for the multiple RPC request messages includes generating a third RPC request directed to the second processor and a fourth RPC request directed to the second processor.

[0119] Embodiment 5. A method according to any one of Embodiments 1 to 4, wherein the at least one GVM includes a first GVM and a second GVM, the multiple RPC sources include the first GVM and the second GVM, and the first multiple RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, generating the multiple RPC request messages from the first multiple RPC requests includes generating a first RPC request message from the first RPC request and generating a second RPC request message from the second RPC request, transmitting the multiple RPC request messages from the at least one first virtual RPC module to the memory includes pushing the first RPC request message to a first queue for the first GVM and pushing the second RPC request message to a second queue for the second GVM, and retrieving the multiple RPC request messages from the memory through the second virtual RPC module includes retrieving the first RPC request message from the first queue for the first GVM and retrieving the second RPC request message from the second queue for the second GVM.

[0120] Embodiment 6. A method according to any one of embodiments 1 to 4, wherein the at least one GVM includes a first GVM and a second GVM, the multiple RPC sources include the first GVM and the second GVM, the first multiple RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, generating the multiple RPC request messages from the first multiple RPC requests includes generating a first RPC request message from the first RPC request by the first virtual RPC module executed by the first GVM, and generating a second RPC request message from the second RPC request by the first virtual RPC module executed by the second GVM, and transmitting the multiple RPC request messages from the at least one first virtual RPC module to The memory includes transmitting the first RPC request message to the memory through the first virtual RPC module executed by the first GVM, and transmitting the second RPC request message to the memory through the first virtual RPC module executed by the second GVM, and the method also includes: transmitting a first RPC request notification for the first GVM from the first virtual RPC module executed by the first GVM to the second virtual RPC module; and transmitting a second RPC request notification for the second GVM from the first virtual RPC module executed by the second GVM to the second virtual RPC module, wherein retrieving the multiple RPC request messages from the memory through the second virtual RPC module includes retrieving the first RPC request message from the memory in response to receiving the first RPC request notification, and retrieving the second RPC request message from the memory in response to receiving the second RPC request notification.

[0121] Embodiment 7. A method according to any one of claims 1 to 6, wherein the multiple RPC sources include a first application and a second application, and the first multiple RPC requests include a first RPC request from the first application and a second RPC request from the second application, and generating the second multiple RPC requests for the multiple RPC request messages includes generating a third RPC request from the first application and generating a fourth RPC request from the second application, the method further comprising: pushing the third RPC request to a first thread pool for the first application; and pushing the fourth RPC request to a second thread pool for the second application.

[0122] Embodiment 8. A method according to any one of claims 1 to 7, wherein generating the multiple RPC request messages from the first multiple RPC requests includes using data of the multiple RPC request messages from a first buffer and buffer properties of the first buffer to generate the multiple RPC request messages, and generating the second multiple RPC requests from the multiple RPC request messages includes: mapping a second buffer using the buffer properties; storing the data of the multiple RPC request messages to the second buffer; and using the data of the multiple RPC request messages from the second buffer to generate the second multiple RPC requests.

[0123] Embodiment 9. A method according to any one of embodiments 1 to 8, wherein: the first plurality of RPC requests includes at least one RPC request from a first RPC source among the plurality of RPC sources; generating the plurality of RPC request messages from the first plurality of RPC requests includes using at least one file descriptor for the data of at least one RPC request message from a first persistent buffer to generate the at least one RPC request message; and the method further includes: mapping a second persistent buffer for use by the first RPC source; retrieving the data of the at least one RPC request message from the at least one RPC request message using the at least one file descriptor; and storing the data of the at least one RPC request message to the second persistent buffer, wherein generating the second plurality of RPC requests from the plurality of RPC request messages can include using the data of the at least one RPC request message from the second persistent buffer to generate at least one RPC request among the second plurality of RPC requests.

[0124] Embodiment 10. According to the method described in any one of Embodiments 1 to 9, the method further includes: setting process attributes of the multiple RPC sources, wherein generating the multiple RPC request messages from the first multiple RPC requests includes generating the multiple RPC request messages from the first multiple RPC requests based on the process attributes, and using the process attributes from the multiple RPC request messages to set the process attributes for implementing the second multiple RPC requests.

[0125] Embodiment 11. According to the method described in any one of Embodiments 1 to 10, the method further includes: receiving a first plurality of RPC results for the second plurality of RPC requests; generating a plurality of RPC result messages from the first plurality of RPC results; transmitting the plurality of RPC result messages from the second virtual RPC module to the memory; retrieving the plurality of RPC result messages from the memory through the at least one first virtual RPC module; and transmitting the plurality of RPC result messages from the at least one first virtual RPC module to the plurality of RPC sources.

[0126] Embodiment 12. The method according to embodiment 11, wherein the at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, and generating the plurality of RPC result messages from the first plurality of RPC results includes generating a first RPC result message from the first RPC result and generating a second RPC result from the second RPC result. C result message, transmitting the multiple RPC result messages from the second virtual RPC module to the memory includes pushing the first RPC result message to the first queue of the first GVM, and pushing the second RPC result message to the second queue of the second GVM, and retrieving the multiple RPC result messages from the memory through the at least one first virtual RPC module includes retrieving the first RPC result message from the first queue of the first GVM through the first virtual RPC module executed by the first GVM, and retrieving the second RPC result message from the second queue of the second GVM through the first virtual RPC module executed by the second GVM.

[0127] Embodiment 13. A method according to any one of Embodiments 11 or 12, wherein the at least one GVM includes a first GVM and a second GVM, and the multiple RPC sources include the first GVM and the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM, the first multiple RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, generating the multiple RPC result messages from the first multiple RPC results includes generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result, and transmitting the multiple RPC result messages from the second virtual RPC module to the memory includes transmitting the first RPC result message and the second RPC result message to the memory. The method further comprises: transmitting a first RPC result notification for the first GVM from the second virtual RPC module to the first virtual RPC module executed by the first GVM; and transmitting a second RPC result notification for the second GVM from the second virtual RPC module to the first virtual RPC module executed by the second GVM, wherein retrieving the multiple RPC result messages from the memory through the at least one first virtual RPC module comprises: in response to receiving the first RPC result notification, retrieving the first RPC result message from the memory through the first virtual RPC module executed by the first GVM; and in response to receiving the second RPC result notification, retrieving the second RPC result message from the memory through the first virtual RPC module executed by the second GVM.

[0128] Embodiment 14. A method according to any one of Embodiments 11 to 13, wherein: the first plurality of RPC requests includes a first RPC request from a first RPC source among the plurality of RPC sources; the second plurality of RPC requests includes a second RPC request derived from the first RPC request; the first plurality of RPC results for the second plurality of RPC requests includes a first RPC result for the second RPC request; generating the plurality of RPC result messages from the first plurality of RPC results includes generating the first RPC result message using at least one file descriptor for the first RPC result from a first persistent buffer; and retrieving the plurality of RPC result messages from the memory through the at least one first virtual RPC module includes retrieving the at least one file descriptor for the first RPC result from a second persistent buffer, the method further comprising: releasing the first persistent buffer storing the at least one file descriptor for the first RPC result; and releasing the second persistent buffer storing the at least one file descriptor for the first RPC result.

[0129] Embodiment 15. A method according to any one of embodiments 1 to 14, wherein the multiple RPC sources include one or more of the following: multiple client virtual machines, multiple applications running on the client virtual machines, or at least one application running on each of the multiple client virtual machines.

[0130] Computer program code or "program code" for execution on a programmable processor to perform the operations of the various embodiments may be written in a high-level programming language (such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic), a structured query language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or program stored on a computer-readable storage medium as used in this application may refer to machine language code (such as object code) in a format that can be understood by a processor.

[0131] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter", "then", "next", etc. are not intended to limit the order of operations; these words are only used to guide the reader to read the description of the method. In addition, any reference to a claim element in singular form (e.g., a reference using the article "one", "an", or "said") should not be interpreted as limiting the element to a singular.

[0132] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with the various embodiments may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Although the technician may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as departing from the scope of the claims.

[0133] The hardware for implementing the various exemplary logics, logic blocks, modules and circuits described in conjunction with the embodiments disclosed herein can be implemented or executed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination thereof designed to perform the functions described herein. Although a general-purpose processor can be a microprocessor, in an alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods can be performed by circuits specific to a given function.

[0134] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, each function can be stored as one or more instructions or codes on a non-transient computer-readable medium or a non-transient processor-readable medium. The operation of the method or algorithm disclosed herein can be implemented in a processor executable software module, which can reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium can be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination is also included in the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0135] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Therefore, the present disclosure is not intended to be limited to the embodiments and implementations described herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for implementing a remote procedure call (RPC) executed in a first processor of a computing device, wherein the first processor is configured to execute a plurality of guest virtual machines (GVMs) in parallel, the method comprising: receiving, by at least one first virtual RPC module executed by at least one GVM of the plurality of GVMs, a first plurality of RPC requests from a plurality of RPC sources concurrently executed by the at least one GVM; generating, by the at least one first virtual RPC module, a plurality of RPC request messages from the first plurality of RPC requests; transmitting the plurality of RPC request messages from the at least one first virtual RPC module to a memory of the computing device; retrieving, by a second virtual RPC module executed by the first processor, the plurality of RPC request messages from the memory; as well as A second plurality of RPC requests is generated for the plurality of RPC request messages through the second virtual RPC module. 2 . The method of claim 1 , wherein receiving the first plurality of RPC requests comprises receiving the first plurality of RPC requests concurrently.

3. The method according to claim 1, wherein: The first plurality of RPC requests include a first RPC request and a second RPC request from a first RPC source among the plurality of RPC sources; The first RPC request is directed to a second processor of the computing device and the second RPC request is directed to a third processor of the computing device; and Generating the second plurality of RPC requests for the plurality of RPC request messages includes generating a third RPC request directed to the second processor and a fourth RPC request directed to the third processor.

4. The method according to claim 1, wherein: The first plurality of RPC requests include a first RPC request from a first RPC source among the plurality of RPC sources and a second RPC request from a second RPC source among the plurality of RPC sources; The first RPC request and the second RPC request are directed to a second processor of the computing device; and Generating the second plurality of RPC requests for the plurality of RPC request messages includes generating a third RPC request directed to the second processor and a fourth RPC request directed to the second processor.

5. The method according to claim 1, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, and the first plurality of RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM; Generating the plurality of RPC request messages from the first plurality of RPC requests comprises generating a first RPC request message from the first RPC request and generating a second RPC request message from the second RPC request; transmitting the plurality of RPC request messages from the at least one first virtual RPC module to the memory comprises pushing the first RPC request message to a first queue for the first GVM and pushing the second RPC request message to a second queue for the second GVM; and Retrieving, by the second virtual RPC module, the plurality of RPC request messages from the memory includes retrieving the first RPC request message from the first queue for the first GVM and retrieving the second RPC request message from the second queue for the second GVM.

6. The method according to claim 1, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; Generating the plurality of RPC request messages from the first plurality of RPC requests comprises: generating, by the first virtual RPC module executed by the first GVM, a first RPC request message from the first RPC request; and generating, by the first virtual RPC module executed by the second GVM, a second RPC request message from the second RPC request; and Transmitting the plurality of RPC request messages from the at least one first virtual RPC module to the memory comprises: transmitting the first RPC request message to the memory through the first virtual RPC module executed by the first GVM; and transmitting the second RPC request message to the memory through the first virtual RPC module executed by the second GVM, The method further comprises: transmitting a first RPC request notification for the first GVM from the first virtual RPC module executed by the first GVM to the second virtual RPC module; and transmitting a second RPC request notification for the second GVM from the first virtual RPC module executed by the second GVM to the second virtual RPC module, Wherein retrieving the plurality of RPC request messages from the memory by the second virtual RPC module comprises: retrieving the first RPC request message from the memory in response to receiving the first RPC request notification; and The second RPC request message is retrieved from the memory in response to receiving the second RPC request notification.

7. The method according to claim 1, wherein: The plurality of RPC sources include a first application and a second application, and the first plurality of RPC requests include a first RPC request from the first application and a second RPC request from the second application; and generating the second plurality of RPC requests for the plurality of RPC request messages comprises generating a third RPC request from the first application and generating a fourth RPC request from the second application, The method further comprises: Pushing the third RPC request to a first thread pool for the first application; as well as The fourth RPC request is pushed to a second thread pool for the second application.

8. The method of claim 1, wherein: Generating the plurality of RPC request messages from the first plurality of RPC requests comprises generating the plurality of RPC request messages using data of the plurality of RPC request messages from a first buffer and buffer attributes of the first buffer; and Generating the second plurality of RPC requests from the plurality of RPC request messages comprises: mapping a second buffer using the buffer attributes; storing the data of the plurality of RPC request messages in the second buffer; and The second plurality of RPC requests are generated using the data of the plurality of RPC request messages from the second buffer.

9. The method according to claim 1, wherein: The first plurality of RPC requests includes at least one RPC request from a first RPC source among the plurality of RPC sources; and Generating the plurality of RPC request messages from the first plurality of RPC requests comprises generating the at least one RPC request message using at least one file descriptor for the data for the at least one RPC request message from a first persistent buffer, the method further comprising: Mapping a second persistent buffer for use by the first RPC source; retrieving the data of the at least one RPC request message from the at least one RPC request message using the at least one file descriptor; and storing the data of the at least one RPC request message in the second persistent buffer, Wherein generating the second plurality of RPC requests from the plurality of RPC request messages comprises using the data of the at least one RPC request message from the second persistent buffer to generate at least one RPC request in the second plurality of RPC requests.

10. The method according to claim 1, further comprising: setting a process attribute of the plurality of RPC sources, wherein generating the plurality of RPC request messages from the first plurality of RPC requests comprises generating the plurality of RPC request messages from the first plurality of RPC requests based on the process attribute; as well as The process attributes are set using the process attributes from the plurality of RPC request messages for implementing the second plurality of RPC requests.

11. The method according to claim 1, further comprising: receiving a first plurality of RPC results for the second plurality of RPC requests; generating a plurality of RPC result messages from the first plurality of RPC results; transmitting the plurality of RPC result messages from the second virtual RPC module to the memory; retrieving, by the at least one first virtual RPC module, the plurality of RPC result messages from the memory; as well as The plurality of RPC result messages are transmitted from the at least one first virtual RPC module to the plurality of RPC sources.

12. The method according to claim 11, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; Generating the plurality of RPC result messages from the first plurality of RPC results comprises generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result; Transmitting the plurality of RPC result messages from the second virtual RPC module to the memory includes pushing the first RPC result message to a first queue of the first GVM, and pushing the second RPC result message to a second queue of the second GVM; and Retrieving, by the at least one first virtual RPC module, the plurality of RPC result messages from the memory comprises: retrieving, by the first virtual RPC module executed by the first GVM, the first RPC result message from the first queue of the first GVM; as well as The second RPC result message is retrieved from the second queue of the second GVM by the first virtual RPC module executed by the second GVM.

13. The method according to claim 11, wherein: The at least one GVM includes a first GVM and a second GVM, and the plurality of RPC sources include the first GVM and the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; The first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM; Generating the plurality of RPC result messages from the first plurality of RPC results comprises generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result; and transmitting the plurality of RPC result messages from the second virtual RPC module to the memory includes transmitting the first RPC result message and the second RPC result message to the memory, The method further includes: transmitting a first RPC result notification for the first GVM from the second virtual RPC module to the first virtual RPC module executed by the first GVM; and transmitting a second RPC result notification for the second GVM from the second virtual RPC module to the first virtual RPC module executed by the second GVM, Wherein retrieving the plurality of RPC result messages from the memory by the at least one first virtual RPC module comprises: In response to receiving the first RPC result notification, retrieving, by the first virtual RPC module executed by the first GVM, the first RPC result message from the memory; and In response to receiving the second RPC result notification, the second RPC result message is retrieved from the memory by the first virtual RPC module executed by the second GVM.

14. The method according to claim 11, wherein: The first plurality of RPC requests includes a first RPC request from a first RPC source among the plurality of RPC sources; The second plurality of RPC requests includes a second RPC request derived from the first RPC request; the first plurality of RPC results for the second plurality of RPC requests including a first RPC result for the second RPC request; Generating the plurality of RPC result messages from the first plurality of RPC results comprises generating a first RPC result message using at least one file descriptor for the first RPC result from a first persistent buffer; retrieving, by the at least one first virtual RPC module, the plurality of RPC result messages from the memory comprises retrieving, from a second persistent buffer, the at least one file descriptor for the first RPC result, The method further comprises: releasing the first persistent buffer storing the at least one file descriptor for the first RPC result; as well as The second persistent buffer storing the at least one file descriptor for the first RPC result is released.

15. The method of claim 1, wherein the plurality of RPC sources comprises one or more of: a plurality of client virtual machines, a plurality of applications running on the client virtual machines, or at least one application running on each of the plurality of client virtual machines.

16. A computing device, the computing device comprising: Memory; as well as A first processor, the first processor being communicatively connected to the memory and configured to execute a plurality of guest virtual machines (GVMs) in parallel and being configured with processor-executable instructions for: receiving, by at least one first virtual remote procedure call (RPC) module executed by at least one GVM of the plurality of GVMs, a first plurality of RPC requests from a plurality of RPC sources concurrently executed by the at least one GVM; generating, by the at least one first virtual RPC module, a plurality of RPC request messages from the first plurality of RPC requests; transmitting the plurality of RPC request messages from the at least one first virtual RPC module to the memory; retrieving the plurality of RPC request messages from the memory by a second virtual RPC module; as well as A second plurality of RPC requests is generated for the plurality of RPC request messages through the second virtual RPC module.

17. The computing device of claim 16, wherein the first processor is further configured to receive the first plurality of RPC requests by concurrently receiving the first plurality of RPC requests.

18. The computing device of claim 16, further comprising a second processor and a third processor communicatively connected to the first processor, wherein: The first plurality of RPC requests include a first RPC request and a second RPC request from a first RPC source among the plurality of RPC sources; The first RPC request is directed to a second processor of the computing device and the second RPC request is directed to a third processor of the computing device; and The first processor is also configured with processor-executable instructions for generating the second plurality of RPC requests for the plurality of RPC request messages by generating a third RPC request directed to the second processor and a fourth RPC request directed to the third processor.

19. The computing device of claim 16, further comprising a second processor communicatively connected to the first processor, wherein: The first plurality of RPC requests include a first RPC request from a first RPC source among the plurality of RPC sources and a second RPC request from a second RPC source among the plurality of RPC sources; The first RPC request and the second RPC request are directed to a second processor of the computing device; and The first processor is also configured with processor-executable instructions for generating the second plurality of RPC requests for the plurality of RPC request messages by generating a third RPC request directed to the second processor and a fourth RPC request directed to the second processor.

20. The computing device of claim 16, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, and the first plurality of RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the plurality of RPC request messages from the first plurality of RPC requests by generating a first RPC request message from the first RPC request and generating a second RPC request message from the second RPC request; transferring the plurality of RPC request messages from the at least one first virtual RPC module to the memory by pushing the first RPC request message to a first queue for the first GVM and pushing the second RPC request message to a second queue for the second GVM; as well as The plurality of RPC request messages are retrieved from the memory by the second virtual RPC module by retrieving the first RPC request message from the first queue for the first GVM and retrieving the second RPC request message from the second queue for the second GVM.

21. The computing device of claim 16, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC requests include a first RPC request from the first GVM and a second RPC request from the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; and The first processor is also configured with processor-executable instructions for performing the following operations: Generating the plurality of RPC request messages from the first plurality of RPC requests by: generating, by the first virtual RPC module executed by the first GVM, a first RPC request message from the first RPC request; and generating, by the first virtual RPC module executed by the second GVM, a second RPC request message from the second RPC request; The plurality of RPC request messages are transmitted from the at least one first virtual RPC module to the memory by: transmitting, by the first virtual RPC module executed by the first GVM, the first RPC request message to the memory; as well as transmitting, by the first virtual RPC module executed by the second GVM, the second RPC request message to the memory; transmitting a first RPC request notification for the first GVM from the first virtual RPC module executed by the first GVM to the second virtual RPC module; transmitting a second RPC request notification for the second GVM from the first virtual RPC module executed by the second GVM to the second virtual RPC module; as well as Retrieving the plurality of RPC request messages from the memory by the second virtual RPC module in the following manner: retrieving the first RPC request message from the memory in response to receiving the first RPC request notification; as well as The second RPC request message is retrieved from the memory in response to receiving the second RPC request notification.

22. The computing device of claim 16, wherein: The plurality of RPC sources include a first application and a second application, and the first plurality of RPC requests include a first RPC request from the first application and a second RPC request from the second application; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the second plurality of RPC requests for the plurality of RPC request messages by generating a third RPC request from the first application and generating a fourth RPC request from the second application; Pushing the third RPC request to a first thread pool for the first application; as well as The fourth RPC request is pushed to a second thread pool for the second application.

23. The computing device of claim 16, wherein the first processor is further configured with processor-executable instructions to: generating the plurality of RPC request messages from the first plurality of RPC requests by utilizing data of the plurality of RPC request messages from a first buffer and a buffer attribute of the first buffer to generate the plurality of RPC request messages; as well as Generating the second plurality of RPC requests from the plurality of RPC request messages by: mapping a second buffer using the buffer attributes; storing the data of the plurality of RPC request messages in the second buffer; as well as The second plurality of RPC requests are generated using the data of the plurality of RPC request messages from the second buffer.

24. The computing device of claim 16, wherein: The first plurality of RPC requests includes at least one RPC request from a first RPC source among the plurality of RPC sources; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the plurality of RPC request messages from the plurality of RPC requests by generating the at least one RPC request message using at least one file descriptor for the data for the at least one RPC request message from a first persistent buffer; Mapping a second persistent buffer for use by the first RPC source; retrieving the data of the at least one RPC request message from the at least one RPC request message using the at least one file descriptor; storing the data of the at least one RPC request message in the second persistent buffer; as well as The second plurality of RPC requests are generated from the plurality of RPC request messages by using the data of the at least one RPC request message from the second persistent buffer to generate at least one RPC request of the second plurality of RPC requests.

25. The computing device of claim 16, wherein the first processor is further configured with processor-executable instructions to: Setting process attributes of the multiple RPC sources; generating the plurality of RPC request messages from the first plurality of RPC requests by generating the plurality of RPC request messages from the first plurality of RPC requests based on the process attributes; and The process attributes are set using the process attributes from the plurality of RPC request messages for implementing the second plurality of RPC requests.

26. The computing device of claim 16, wherein the first processor is further configured with processor-executable instructions to: receiving a first plurality of RPC results for the second plurality of RPC requests; generating a plurality of RPC result messages from the first plurality of RPC results; transmitting the plurality of RPC result messages from the second virtual RPC module to the memory; retrieving, by the at least one first virtual RPC module, the plurality of RPC result messages from the memory; as well as The plurality of RPC result messages are transmitted from the at least one first virtual RPC module to the plurality of RPC sources.

27. The computing device of claim 26, wherein: The at least one GVM includes a first GVM and a second GVM, the plurality of RPC sources include the first GVM and the second GVM, the first plurality of RPC results include a first RPC result for the first GVM and a second RPC result for the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the plurality of RPC result messages from the first plurality of RPC results by generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result; transferring the plurality of RPC result messages from the second virtual RPC module to the memory by pushing the first RPC result message to a first queue of the first GVM and pushing the second RPC result message to a second queue of the second GVM; as well as Retrieving the plurality of RPC result messages from the memory by the at least one first virtual RPC module in the following manner: retrieving, by the first virtual RPC module executed by the first GVM, the first RPC result message from the first queue of the first GVM; and The second RPC result message is retrieved from the second queue of the second GVM by the first virtual RPC module executed by the second GVM.

28. The computing device of claim 26, wherein: The at least one GVM includes a first GVM and a second GVM, and the plurality of RPC sources include the first GVM and the second GVM, and the at least one first virtual RPC module includes a first virtual RPC module executed by the first GVM and a first virtual RPC module executed by the second GVM; The first plurality of RPC results includes a first RPC result for the first GVM and a second RPC result for the second GVM; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the plurality of RPC result messages from the first plurality of RPC results by generating a first RPC result message from the first RPC result and generating a second RPC result message from the second RPC result; as well as transmitting the plurality of RPC result messages from the second virtual RPC module to the memory by transmitting the first RPC result message and the second RPC result message to the memory; transmitting a first RPC result notification for the first GVM from the second virtual RPC module to the first virtual RPC module executed by the first GVM, and transmitting a second RPC result notification for the second GVM from the second virtual RPC module to the first virtual RPC module executed by the second GVM; as well as Retrieving the plurality of RPC result messages from the memory by the at least one first virtual RPC module in the following manner: in response to receiving the first RPC result notification, retrieving, by the first virtual RPC module executed by the first GVM, the first RPC result message from the memory; as well as In response to receiving the second RPC result notification, the second RPC result message is retrieved from the memory by the first virtual RPC module executed by the second GVM.

29. The computing device of claim 26, wherein: The first plurality of RPC requests includes a first RPC request from a first RPC source among the plurality of RPC sources; The second plurality of RPC requests includes a second RPC request derived from the first RPC request; the first plurality of RPC results for the second plurality of RPC requests include a first RPC result for the second RPC request; and The first processor is also configured with processor-executable instructions for performing the following operations: generating the plurality of RPC result messages from the first plurality of RPC results by generating a first RPC result message using at least one file descriptor for the first RPC result from a first persistent buffer; retrieving, by the at least one first virtual RPC module, the plurality of RPC result messages from the memory by retrieving the at least one file descriptor for the first RPC result from a second persistent buffer; releasing the first persistent buffer storing the at least one file descriptor for the first RPC result; as well as The second persistent buffer storing the at least one file descriptor for the first plurality of RPC results is released.

30. A computing device, the computing device comprising: means for receiving, by at least one first virtual remote procedure call (RPC) module executed by at least one GVM of a plurality of GVMs, a first plurality of RPC requests from a plurality of RPC sources concurrently executed by the at least one GVM; means for generating a plurality of RPC request messages from said first plurality of RPC requests; means for transmitting the plurality of RPC request messages to a memory of the computing device; means for retrieving said plurality of RPC request messages from said memory; as well as Means for generating a second plurality of RPC requests for the plurality of RPC request messages.

Images