Patent Description:
Virtualization allows multiple operating systems to be run on one physical device. Hardware virtualization refers to the creation of a virtual machine that acts like a real computer with an operating system. Software executed on the virtual machine is separated from the underlying hardware resources. Different operating systems may run independently from each other in a virtualization environment provided by a processor to which a virtualization is applied. The virtualization may provide isolation, high availability, workload balancing, sandboxing, hardware agnostic software, etc..

Processors, memories, intellectual properties (IPs) (e.g., functional circuitries or blocks) having various functions may be included in, or implemented by, a virtualized system. Such various hardware devices may be shared by various operating systems. However, current virtualization techniques suffer from software compatibility issues and portability degradation.

<CIT> discloses a virtualization infrastructure that allows multiple guest partitions to run within a host hardware partition.

<CIT> discloses an I/O (Input/Output) adapter device that can present itself as a network backend driver with an emulated network backend driver interface to a corresponding network frontend driver executing from an operating system running on a host device independent of a virtualization or non-virtualization environment.

At least one example embodiment of the present disclosure provides a system for allowing multiple operating systems to be run on one physical device according to claim <NUM> and a method for implementing such system according to claim <NUM>.

Illustrative, non-limiting example embodiments will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings.

Various example embodiments will be described more fully with reference to the accompanying drawings, in which embodiments are shown. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Like reference numerals refer to like elements throughout this application.

<FIG> is a block diagram illustrating a virtualized system according to an example embodiment.

Referring to <FIG>, a virtualized system <NUM> includes a processor <NUM>, at least one hardware input/output (I/O) device <NUM>, and at least one hardware interface device <NUM>. The processor <NUM> includes a host operating system (OS) <NUM>, at least one guest operating system <NUM>, and a hypervisor <NUM>.

The processor <NUM> provides a function for implementing a virtualization environment. The host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM> may run or operate on the virtualization environment.

For example, the host operating system <NUM> may run on a host virtual machine of the virtualization environment. The at least one guest operating system <NUM> may run on at least one guest virtual machine of the virtualization environment. In an embodiment, the at least one guest operating system <NUM> runs or operates independently from the host operating system <NUM>. The hypervisor <NUM> implements or generates the virtualization environment using a function of the processor <NUM>, and may generate (or create) and control the host virtual machine and the at least one guest virtual machine on the virtualization environment.

For convenience of illustration, <FIG> illustrates only one guest operating system <NUM>. However, example embodiments are not limited thereto, and the number of guest operating systems running on the hypervisor <NUM> may be variously determined according to the virtualization environment. For example, as will be described with reference to <FIG>, the virtualized system may include two or more guest operating systems.

In addition, for convenience of illustration, <FIG> illustrates that the host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM> are included in the processor <NUM>. However, example embodiments are not limited thereto, and the host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM> may be loaded into a memory device as software programs and may be executed by the processor <NUM>.

For example, as will be described with reference to <FIG>, the virtualized system may further include a memory device and a storage device. The memory device may store data and program codes. Software program codes for implementing the virtualization environment, such as the host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM>, etc., may be loaded into the memory device, and the loaded software program codes may be executed by the processor <NUM>. The storage device may store the host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM>. For example, while the virtualized system is booted up, the software program codes stored in the storage device may be loaded into the memory device according to a booting sequence, and the processor <NUM> may provide the virtualization environment based on the loaded software program codes. As such, the memory device may function as a working memory of the virtualized system. For example, the memory device may be implemented with a volatile memory such as a dynamic random access memory (DRAM), a static random access memory (SRAM), etc., but example embodiments are not limited thereto. For example, the storage device may be implemented with a nonvolatile memory such as an electrically erasable programmable read-only memory (EEPROM), a flash memory, a phase-change random access memory (PRAM), a resistive random access memory (RRAM), a magnetic random access memory (MRAM), a ferroelectric random access memory (FRAM), etc., but example embodiments are not limited thereto.

An example configuration of the virtualization environment will be described with reference to <FIG>.

The at least one hardware input/output device <NUM> may be controlled by the host operating system <NUM> and the at least one guest operating system <NUM>. For example, the at least one hardware input/output device <NUM> may includes at least one of various physical hardware devices such as a memory device, a camera, a graphics processing unit (GPU), a neural processing unit (NPU), a peripheral component interconnect express (PCle) device, a universal flash storage (UFS) device, etc. Although <FIG> illustrates only one hardware input/output device, example embodiments are not limited thereto, and the number of hardware input/output devices may be variously determined according to example embodiments. For example, as will be described with reference to <FIG>, the virtualized system may include two or more hardware input/output devices.

The at least one hardware interface device <NUM> supports communication between the at least one guest operating system <NUM> and the at least one hardware input/output device <NUM>. For example, the at least one hardware interface device <NUM> may be a physical hardware device for communicating with the at least one hardware input/output device <NUM>. Although <FIG> illustrates only one hardware interface device, example embodiments are not limited thereto, and the number of hardware interface devices may be variously determined according to the number of guest operating systems and/or the number of hardware input/output devices. For example, as will be described with reference to <FIG> and <FIG>, the virtualized system may include two or more hardware interface devices.

In some example embodiments, as described with reference to <FIG> and as will be described with reference to <FIG>, the at least one hardware interface device <NUM> may be implemented and/or formed independently from the at least one guest operating system <NUM> and the hypervisor <NUM>. In other example embodiments, as will be described with reference to <FIG>, the at least one hardware interface device <NUM> may be implemented and/or formed to be included in the hypervisor <NUM>.

An example configuration of the at least one hardware interface device <NUM> will be described with reference to <FIG> and <FIG>.

In an example embodiment, the virtualized system <NUM> operates based on a virtual I/O device (VIRTIO) specification (or standard).

<FIG> is a flowchart illustrating a method of operating a virtualized system according to an example embodiment.

Referring to <FIG> and <FIG>, in a method of operating a virtualized system according to an example embodiment, the virtualized system <NUM> provides (or generates) the virtualization environment by executing the host operating system <NUM>, the at least one guest operating system <NUM> and the hypervisor <NUM> using the processor <NUM> (step S100). The processor <NUM> provides the function for the virtualization environment. The host operating system <NUM> runs on the virtualization environment. The at least one guest operating system <NUM> runs on the at least one virtual machine of the virtualization environment. The hypervisor <NUM> implements the virtualization environment using a function of the processor <NUM>, and generates and controls the at least one virtual machine on the virtualization environment.

The at least one hardware input/output device <NUM> is controllable by the host operating system <NUM> and the at least one guest operating system <NUM>. A scheme or manner of controlling the at least one hardware input/output device <NUM> may be changed (or may vary) according to whether a subject or an agent controlling the at least one hardware input/output device <NUM> is the host operating system <NUM> or the at least one guest operating system <NUM>.

For example, when the at least one hardware input/output device <NUM> is to be controlled by the at least one guest operating system <NUM> (step S200: YES), the at least one hardware input/output device <NUM> is controlled using the at least one hardware interface device <NUM> (step S300). The at least one hardware interface device <NUM> supports the communication between the at least one guest operating system <NUM> and the at least one hardware input/output device <NUM>. <FIG> illustrates the operation of step S300 by an arrowed line between the at least one guest operating system <NUM> and the at least one hardware interface device <NUM>, and an arrowed line between the at least one hardware interface device <NUM> and the at least one hardware input/output device <NUM>.

For example, when the at least one hardware input/output device <NUM> is to be controlled by the host operating system <NUM> (step S200: NO), the at least one hardware input/output device <NUM> is controlled without using the at least one hardware interface device <NUM> (step S400). <FIG> illustrates the operation of step S400 by an arrowed line between the host operating system <NUM> and the at least one hardware input/output device <NUM>.

A virtualization for a hardware input/output device may be implemented using only software. However, when only software is used in this manner, performance of the hardware input/output device may be degraded or deteriorated as complex software layers are implemented. Further, when the software is used in this manner, compatibility and portability of the software may be degraded or deteriorated as a dedicated hardware input/output device is used.

In the virtualized system and the method of operating the virtualized system according to an example embodiment, the virtualization for the hardware input/output device is instead implemented using hardware. For example, the virtualized system <NUM> may include the at least one hardware interface device <NUM> supporting the communication between the at least one guest operating system <NUM> and the at least one hardware input/output device <NUM>. The at least one guest operating system <NUM> may control the at least one hardware input/output device <NUM> using the at least one hardware interface device <NUM>.

In addition, as will be described later, the virtualized system may include a virtualization driver that controls the guest operating system <NUM> and the virtualized input/output device using an interface provided by the virtualized input/output device. The non-virtualized hardware input/output device and the virtualized hardware input/output device may provide the same interface, and thus the virtualization driver in the guest operating system <NUM> may control both the virtualized and non-virtualized hardware input/output devices.

Therefore, the guest operating system <NUM> may communicate with a hardware input/output device <NUM> that provides the same interface as the virtualized hardware input/output device, and may communicate with the hardware input/output device <NUM> without passing through complex software layers for implementing the virtualization. Accordingly, the performance of the hardware input/output device <NUM> may be maintained and the performance degradation may be prevented, and the compatibility and portability of the software may be guaranteed or ensured.

<FIG> is a diagram for describing a virtualization environment implemented by a virtualized system according to an example embodiment.

Referring to <FIG>, a virtualized system <NUM> may include system hardware <NUM> and software runs on a virtualization environment provided by the system hardware <NUM>. The software may include a hypervisor <NUM> and a plurality of virtual machines <NUM> and <NUM>. For convenience of illustration, <FIG> illustrates only two virtual machines <NUM> and <NUM>, which are a host virtual machine <NUM> and a guest virtual machine <NUM>. However, example embodiments are not limited thereto, and the number of virtual machines installed on the hypervisor <NUM> may be variously determined according to example embodiments. For example, the virtualized system <NUM> may include two or more guest virtual machines.

The system hardware <NUM> may include a processor PRC that provides the virtualization environment, a memory device MEM, one or more intellectual properties IPs, a storage device STG, a hardware interface device HW_IF, and the like.

For example, the processor PRC may be a single processor or may include a plurality of processor cores. When the processor PRC includes the plurality of processor cores, one of the processor cores may correspond to the processor <NUM> in <FIG> that provides the virtualization environment.

For example, the memory device MEM may include at least one volatile memory. The intellectual property IP may include hardware devices having various functions, such as a camera, a GPU, an NPU, and the like. The storage device STG may include at least one nonvolatile memory. The memory device MEM, the intellectual property IP and the storage device STG may correspond to the hardware input/output device <NUM> in <FIG>. In addition, the hardware interface device HW_IF may correspond to the hardware interface device <NUM> in <FIG>.

The virtual machines <NUM> and <NUM> may have various configurations to perform respective functions.

For example, the host virtual machine <NUM> may include a host operating system <NUM> and host applications HAPPs. The host applications HAPP may run or execute on the host operating system <NUM>.

The host operating system <NUM> may include a host virtualization driver vHDRV and a device driver DDRV. The host virtualization driver vHDRV may be a driver for an operation of the virtualization environment. The device driver DDRV may be a driver for directly controlling the processor PRC, the memory device MEM, the intellectual property IP, etc. (e.g., the hardware input/output device <NUM> in <FIG>) included in the system hardware <NUM>. As described with reference to <FIG> and <FIG>, the host operating system <NUM> may directly control the processor PRC, the memory device MEM, the intellectual property IP, etc. (e.g., the hardware input/output device <NUM> in <FIG>) included in the system hardware <NUM>, without using the hardware interface device HW_IF.

In addition, the guest virtual machine <NUM> may include virtual hardware, a guest operating system <NUM> and guest applications GAPPs. The guest applications GAPPs may run or execute on the guest operating system <NUM>.

The virtual hardware may correspond to physical components that are emulated as software in the guest virtual machine <NUM>. In other words, corresponding physical components of the virtualized system <NUM> may be virtualized as the virtual hardware. The virtual hardware may include virtual components emulating the physical components allocated to the guest virtual machine <NUM> among the entire physical components in the system hardware <NUM>. For example, the virtual hardware may include a virtual processor vPRC emulating the processor PRC, a virtual memory device vMEM emulating the memory device MEM, a virtual intellectual property vIP emulating the intellectual property IP, etc..

The guest operating system <NUM> may include a guest virtualization driver vGDRV. The guest virtualization driver vGDRV may be a driver for an operation of the virtualization environment. For example, the guest virtualization driver vGDRV may control the processor PRC, the memory device MEM, the intellectual properties IP (e.g., the hardware input/output device <NUM> in <FIG>) included in the system hardware <NUM> via the virtual processor vPRC, the virtual memory device vMEM and the virtual intellectual property vIP included in the virtual hardware. As described with reference to <FIG> and <FIG>, the guest operating system <NUM> may control the processor PRC, the memory device MEM, the intellectual property IP, etc. (e.g., the hardware input/output device <NUM> in <FIG>) included in the system hardware <NUM>, using the hardware interface device HW_IF.

The guest operating system <NUM> may further include a virtual memory management unit, a state monitor, etc. The virtual memory management unit may allocate a virtual address space of the guest operating system <NUM> to the guest applications GAPPs running on the guest operating system <NUM>, and may manage a mapping operation between a virtual address in the virtual address space and an intermediate physical address of the virtual memory device vMEM included in the virtual hardware. The state monitor may provide state information by monitoring the guest virtual machine <NUM> and/or the guest operating system <NUM>. For example, the state monitor may provide the state information periodically while the guest virtual machine <NUM> operates normally. In this case, the hypervisor <NUM> may determine it is necessary to reboot the guest operating system <NUM> when the state information is not provided for a predetermined time interval.

The hypervisor <NUM> may generate, schedule and manage the plurality of virtual machines <NUM> and <NUM>. The hypervisor <NUM> may provide an interface between the plurality of virtual machines <NUM> and <NUM> and the system hardware <NUM>, and manage an execution of instructions and data transfer associated with the plurality of virtual machines <NUM> and <NUM>. The hypervisor <NUM> may be referred to as a virtual machine monitor or a virtual machine manager.

The hypervisor <NUM> may include an interrupt handler ITR_HD, a device emulator D_EML, and the like.

The interrupt handler ITR_HD may control an operation of the virtualized system <NUM> based on information from the virtual machines <NUM> and <NUM> and/or information from the system hardware <NUM>.

The device emulator D_EML may allocate the physical components to the guest virtual machine <NUM>, and may establish and manage the virtual hardware by emulating the allocated physical components.

The hypervisor <NUM> may further include a virtual memory management unit, a device driver, etc. The virtual memory management unit may allocate one or a plurality of guest memory regions of the memory device MEM included in the system hardware <NUM> to the guest virtual machine <NUM> or the guest operating system <NUM>, and may manage a mapping operation between the intermediate physical address of the virtual memory devices vMEM included in the virtual hardware and a physical address of the memory device MEM. The device driver may directly control the processor PRC, the memory device MEM, the intellectual properties IP (e.g., the hardware input/output device <NUM> in <FIG>) included in the system hardware <NUM>.

Although <FIG> illustrates only one guest virtual machine, example embodiments are not limited thereto. For example, the virtualized system <NUM> may include two or more guest virtual machines, and another guest virtual machine may also be implemented with the same or similar structure to the guest virtual machine <NUM>.

<FIG> and <FIG> are diagrams illustrating examples of a hierarchical structure of a virtualization environment implemented by a virtualized system according to an example embodiment.

Referring to <FIG> and <FIG>, examples where the virtualization environment includes a plurality of guest operating systems GOS1, GOS2 and GOS3 are illustrated.

For example, a virtualization environment may include a plurality of guest operating systems GOS1, GOS2 and GOS3 and applications running on the plurality of guest operating systems GOS1, GOS2 and GOS3. For example, applications APP11 and APP12 may run on the first guest operating system GOS1, the applications APP21 and APP22 may run on the second guest operating system GOS2, and the applications APP31 and APP32 may run on the third guest operating system GOS3. The number of guest operating systems and the number of applications running on each guest operating system may be variously determined according to example embodiments.

A hypervisor HPVS (e.g., <NUM>) may be classified or divided largely into a first type and a second type. <FIG> illustrate the hypervisor HPVS of the first type, and <FIG> illustrates the hypervisor HPVS of the second type. The hypervisor HPVS of the first type in <FIG> may be referred to as a hosted hypervisor, and the hypervisor HPVS of the second type in <FIG> may be referred to as a standalone hypervisor. For example, a representative open source hypervisor may include a kernel-based virtual machine (KVM) of the first type and Xen based hypervisor of the second type.

For example, the hypervisor HPVS of the first type may run on a host operating system HOS as illustrated in <FIG>, or may be included in the host operating system HOS as illustrated in <FIG>. In this case, the host operating system HOS may have a full control with respect to a system hardware SYSHW (e.g., <NUM>). The host operating system HOS may run on the system hardware SYSHW and the applications may run on the host operating system HOS.

For example, the hypervisor HPVS of the second type may run on the system hardware SYSHW and may have a full control with respect to the system hardware SYSHW, as illustrated in <FIG>. In this case, the host operating system is not present in the virtualization hierarchical structure, and one of the guest operating systems GOS1, GOS2 and GOS3 may perform a function of the host operating system. The applications may run on the hypervisor HPVS of the second type.

Hereinafter, example embodiments will be described based on the hypervisor HPVS of the first type in <FIG>, but example embodiments are not limited thereto. Example embodiments may be applied to any virtualized systems including the hypervisor HPVS of the second type in <FIG> or other types.

Hereinafter, example embodiments will be described based on a case where the virtualized system is implemented and/or operate based on the VIRTIO specification. However, example embodiments are not limited thereto, and the virtualized system may be implemented and/or operate based on various specifications associated with or related to the virtualized system.

<FIG> and <FIG> are block diagrams illustrating examples of a virtualized system of <FIG>. The descriptions repeated with <FIG> will be omitted.

Referring to <FIG>, a virtualized system 10a may include a host operating system 200a, a guest operating system 300a, a hypervisor 400a, a hardware input/output device 500a and a hardware interface device 600a.

The guest operating system 300a may include a guest virtualization driver <NUM>. The guest virtualization driver <NUM> may be a driver for an operation of the virtualization environment, and may correspond to the guest virtualization driver vGDRV in <FIG>.

In an example embodiment, when the virtualized system 10a operates based on the VIRTIO specification, the guest virtualization driver <NUM> is implemented in the form of a VIRTIO driver. The VIRTIO driver may control the hardware input/output device 500a by reading and/or writing each field of VIRTIO-MMIO (memory mapped I/O) according to the purpose of fields of VIRTIO-MMIO defined in the VIRTIO specification.

The hardware input/output device 500a may be controlled by the host operating system 200a and the guest operating system 300a. The hardware input/output device 500a may correspond to the processor PRC, the memory device MEM, the intellectual property IP, etc. included in the system hardware <NUM> of <FIG>.

In an example embodiment, when the virtualized system 10a operates based on the VIRTIO specification, the hardware input/output device 500a is implemented in the form of a VIRTIO aware input/output device. A firmware of the VIRTIO aware input/output device 500a may communicate with the VIRTIO driver <NUM> in the guest operating system 300a through the hardware interface device 600a, and a hardware operation corresponding to a control of the VIRTIO driver <NUM> may be performed by operating in compliance with a device operation defined in the VIRTIO specification.

The hardware interface device 600a may support a communication between the guest operating system 300a and the hardware input/output device 500a. The hardware interface device 600a may correspond to the hardware interface device HW_IF included in the system hardware <NUM> of <FIG>.

In some example embodiments, the hardware interface device 600a may be formed and/or implemented independently from the guest operating system 300a and the hypervisor 400a, as illustrated in <FIG>. In other words, the hardware interface device 600a may be implemented as a separate hardware that is not included in the guest operating system 300a and the hypervisor 400a. For example, the hardware interface device 600a may be implemented in hardware separate from hardware including the guest operating system 300a and the hypervisor 400a.

In an example embodiment, when the virtualized system 10a operates based on the VIRTIO specification, the hardware interface device 600a is implemented in the form of a VIRTIO-MMIO compatible hardware interface. The VIRTIO-MMIO compatible hardware interface may be a hardware device compatible with a layout of VIRTIO-MMIO defined in the VIRTIO specification, and may be implemented as a hardware mailbox or memory device.

Although <FIG> illustrates that the hardware input/output device 500a and the hardware interface device 600a are separate hardwares, example embodiments are not limited thereto. For example, the hardware input/output device 500a and the hardware interface device 600a may be implemented as a single hardware. For example, the hardware interface device 600a may be included in the hardware input/output device 500a.

In an example embodiment, the guest operating system 300a controls the hardware input/output device 500a through the guest virtualization driver <NUM> and the hardware interface device 600a. In this embodiment, a control of the hardware input/output device 500a by the guest virtualization driver <NUM> may be provided directly to the hardware interface device 600a without being trapped or handled by the hypervisor 400a. For example, a direct access interrupt DA_ITR may be transmitted between the guest virtualization driver <NUM> and the hardware interface device 600a. For example, the guest virtualization driver <NUM> may provide the direct access interrupt DA_ITR to the hypervisor 400a, and the hypervisor 400a may forward the direct access interrupt DA_ITR to the hardware interface device 600a without the hypervisor 400a performing an operation on the direct access interrupt DA_ITR. <FIG> illustrates the above-described control operation by arrowed solid lines between the guest virtualization driver <NUM>, the hardware interface device 600a and the hardware input/output device 500a.

In an example embodiment, the virtualized system 10a further includes a shared memory <NUM> that is shared by the host operating system 200a and the guest operating system 300a. The guest operating system 300a may exchange data with the hardware input/output device 500a through the guest virtualization driver <NUM> and the shared memory <NUM>. <FIG> illustrates the above-described data exchange operation by arrowed dotted lines between the guest virtualization driver <NUM>, the shared memory <NUM> and the hardware input/output device 500a.

For convenience of illustration, <FIG> illustrates that the shared memory <NUM> is included in the guest operating system 300a. However, example embodiments are not limited thereto. For example, the shared memory <NUM> may be disposed or located separately from the host operating system 200a and the guest operating system 300a, and may be shared by the host operating system 200a and the guest operating system 300a.

The host operating system 200a may include a host virtualization driver <NUM> and a device driver <NUM>. The host virtualization driver <NUM> may be a driver for an operation of the virtualization environment, and may correspond to the host virtualization driver vHDRV in <FIG>. The device driver <NUM> may be a driver for directly controlling the hardware input/output device 500a, and may correspond to the device driver DDRV in <FIG>. For example, the device driver <NUM> may directly control the hardware input/output device 500a without using the hardware interface device 600a. For example, the device driver <NUM> may provide a command or a control signal to the hypervisor 400a and the hypervisor 400a may forward the command or the control signal directly to the hardware input/output device 500a.

In an example embodiments when the virtualized system 10a operates based on the VIRTIO specification, the host virtualization driver <NUM> is implemented in the form of a VIRTIO driver similar to the guest virtualization driver <NUM>, and the device driver <NUM> may be implemented in the form of an input/output driver.

In an example embodiment, the host operating system 200a controls the hardware input/output device 500a through the host virtualization driver <NUM> and the device driver <NUM> without using the hardware interface device 600a. <FIG> illustrates the above-described control operation by arrowed solid lines between the host virtualization driver <NUM>, the device driver <NUM> and the hardware input/output device 500a.

In some example embodiments, the host operating system 200a may run on a Linux™ virtual machine. In this case, the host virtualization driver <NUM> may run on a user space, the device driver <NUM> may run on a Linux ™ kernel as a physical device driver, and the virtualized system may further include virtualized hardware abstraction layer (HAL) servers operating on the user space.

In some example embodiments, the guest operating system 300a may run on an Android Trout™ operating interoperable with (or in conjunction with) the Linux™ virtual machine. In this case, the guest virtualization driver <NUM> may run on the Linux™ kernel, and the virtualized system may further include a HAL and a virtualized HAL operating on the user space. For example, the above-described configurations may be implemented using the VIRTIO aware input/output device without software modification.

Referring to <FIG>, a virtualized system 10b may include a host operating system 200b, a guest operating system 300b, a hypervisor 400b, a hardware input/output device 500b and a hardware interface device 600b.

The host operating system 200b, the guest operating system 300b and the hardware input/output device 500b may be substantially the same as the host operating system 200a, the guest operating system 300a and the hardware input/output device 500a in <FIG>, respectively. The descriptions repeated with <FIG> will be omitted.

The hardware interface device 600b supports a communication between the guest operating system 300b and the hardware input/output device 500b. The hardware interface device 600b may correspond to the hardware interface device HW_IF included in the system hardware <NUM> of <FIG>.

In some example embodiments, the hardware interface device 600b may be formed and/or implemented to be included in the hypervisor 400b, as illustrated in <FIG>. For example, the hardware interface device 600b may be implemented as a hardware emulator included in the hypervisor 400b.

In an example embodiment, when the virtualized system 10a operates based on the VIRTIO specification, the hardware interface device 600b (e.g., the hardware emulator) is implemented in the form of a VIRTIO-MMIO emulator. A read from and/or write to VIRTIO-MMIO of the VIRTIO driver may be trapped and stored by the hypervisor 400b, the hypervisor 400b may update the contents of VIRTIO-MMIO to the VIRTIO aware input/output device if necessary, and the VIRTIO aware input/output device may recognize the contents of the stored MMIO and may perform corresponding hardware operations.

In an example embodiment, the guest operating system 300b controls the hardware input/output device 500b through the guest virtualization driver <NUM> and the hardware interface device 600b (e.g., a hardware emulator). In this case, a control of the hardware input/output device 500b by the guest virtualization driver <NUM> may be trapped or handled by the hypervisor 400b, and may be provided to the hardware interface device 600b. For example, a trapped interrupt T_ITR may be transmitted between the guest virtualization driver <NUM> and the hardware interface device 600b. <FIG> illustrates the above-described control operation by arrowed solid lines between the guest virtualization driver <NUM>, the hardware interface device 600b and the hardware input/output device 500b.

The trapped interrupt T_ITR may be a synchronous interrupt that is referred to as a trap. In an embodiment, an exception occurs while the guest operating system 300b is operating and the guest virtualization driver <NUM> sends the trapped interrupt T_ITR to the hardware interface device 600b when the exception occurs. In response to receiving the trapped interrupt T_ITR, the hardware interface device 600b saves parameters that the guess operating system 300b needs to operate such as stack pointers, registers, program variable, etc. and suspends execution or stops execution of the guest operating system 300b. For example, the trapped interrupt T_ITR may be a signal including information on the type of exception that occurred such as a software or hardware exception with respect to the hardware input/output device 500b. The hardware interface device 600b may perform an action in response to the trapped interrupt T_ITR, restore the registers, stack pointers, variables, etc. of the guest operating system 300b, and resume or restart the guest operating system 300b. For example, the action could cause a reset of the hardware input/output device 500b, output an error message, etc..

In some example embodiments, the virtualized system 10b may further include a shared memory <NUM> that is shared by the host operating system 200b and the guest operating system 300b. The guest operating system 300b may exchange data with the hardware input/output device 500b through the guest virtualization driver <NUM> and the shared memory <NUM>. <FIG> illustrates the above-described data exchange operation by arrowed dotted lines between the guest virtualization driver <NUM>, the shared memory <NUM> and the hardware input/output device 500b.

<FIG> and <FIG> are diagrams for describing an operation of a virtualized system of <FIG> and <FIG>.

Referring to <FIG> and <FIG>, a layout of the MMIO device defined in the VIRTIO specification is illustrated. "Offset" represents an offset from a base, "RW" represents a direction of read R and write W, and "Register" and "Description" represent a name and an operation of each function.

Virtualization environments without peripheral component interconnect (PCI) support (a common situation in embedded devices models) may use a simple memory mapped device ("VIRTIO-MMIO") instead of a PCI device. The VIRTIO-MMIO behavior is based on the PCI device specification. Therefore, most operations including device initialization, queues configuration and buffer transfers are nearly identical to the PCI device.

In some example embodiments, the hardware interface device 600a in <FIG> (e.g., the VIRTIO-MMIO compatible hardware interface) may support all of the read/write illustrated in <FIG> and <FIG>, and the hardware interface device 600b in <FIG> (e.g., the VIRTIO-MMIO emulator) may support some of the read/write illustrated in <FIG> and <FIG>.

<FIG> and <FIG> are block diagrams illustrating a virtualized system according to an example embodiment. The descriptions repeated with <FIG> will be omitted.

Referring to <FIG>, a virtualized system <NUM> includes a processor <NUM>, at least one hardware input/output device <NUM> and a plurality of hardware interface devices <NUM> and <NUM>. The processor <NUM> includes a host operating system <NUM>, a plurality of guest operating systems <NUM> and <NUM> and a hypervisor <NUM>.

The virtualization system <NUM> may be substantially the same as the virtualization system <NUM> of <FIG>, except that the virtualization system <NUM> includes the plurality of guest operating systems <NUM> and <NUM> and the plurality of hardware interface devices <NUM> and <NUM>.

The plurality of guest operating systems <NUM> and <NUM> may include a first guest operating system <NUM> and a second guest operating system <NUM>. The first guest operating system <NUM> may run on a first virtual machine of the virtualization environment. The second guest operating system <NUM> may run on a second virtual machine of the virtualization environment, and may run independently from the first guest operating system <NUM>. For example, each of the plurality of guest operating systems <NUM> and <NUM> may be implemented as described with reference to <FIG>.

The plurality of hardware interface devices <NUM> and <NUM> may include a first hardware interface device <NUM> and a second hardware interface device <NUM>. The first hardware interface device <NUM> may support a communication between the first guest operating system <NUM> and the at least one hardware input/output device <NUM>. The second hardware interface device <NUM> may support a communication between the second guest operating system <NUM> and the at least one hardware input/output device <NUM>. For example, each of the plurality of hardware interface devices <NUM> and <NUM> may be implemented as described with reference to <FIG> and <FIG>.

In some example embodiments, when the virtualized system <NUM> includes the plurality of guest operating systems <NUM> and <NUM>, one hardware interface device may be formed and/or implemented for each guest operating system, and each guest operating system may control the at least one hardware input/output device <NUM> using a corresponding hardware interface device. For example, when the first guest operating system <NUM> wants to control the at least one hardware input/output device <NUM>, the at least one hardware input/output device <NUM> may be controlled using the first hardware interface device <NUM>. For example, when the second guest operating system <NUM> wants to control the at least one hardware input/output device <NUM>, the at least one hardware input/output device <NUM> may be controlled using the second hardware interface device <NUM>.

For convenience of illustration, <FIG> illustrates only two guest operating systems <NUM> and <NUM> and two hardware interface devices <NUM> and <NUM>. However, example embodiments are not limited thereto, and the number of guest operating systems and hardware interface devices may be variously determined according to example embodiments.

Referring to <FIG>, a virtualized system <NUM> includes a processor <NUM>, a plurality of hardware input/output device <NUM> and <NUM>, and a plurality of hardware interface devices <NUM> and <NUM>. The processor <NUM> may include a host operating system <NUM>, at least one guest operating system <NUM> and a hypervisor <NUM>.

The virtualization system <NUM> may be substantially the same as the virtualization system <NUM> of <FIG>, except that the virtualization system <NUM> includes the plurality of hardware input/output device <NUM> and <NUM> and the plurality of hardware interface devices <NUM> and <NUM>.

The plurality of hardware input/output devices <NUM> and <NUM> may include a first hardware input/output device <NUM> and a second hardware input/output device <NUM>. For example, each of the plurality of hardware input/output devices <NUM> and <NUM> may be implemented as described with reference to <FIG>.

The plurality of hardware interface devices <NUM> and <NUM> may include a first hardware interface device <NUM> and a second hardware interface device <NUM>. The first hardware interface device <NUM> may support a communication between the at least one guest operating system <NUM> and the first hardware input/output device <NUM>. The second hardware interface device <NUM> may support a communication between the at least one guest operating system <NUM> and the second hardware input/output device <NUM>. For example, each of the plurality of hardware interface devices <NUM> and <NUM> may be implemented as described with reference to <FIG> and <FIG>.

In some example embodiments, when the virtualized system <NUM> includes the plurality of hardware input/output devices <NUM> and <NUM>, one hardware interface device may be formed and/or implemented for each hardware input/output device, and the least one guest operating system <NUM> may control a corresponding hardware input/output device using a corresponding hardware interface device. For example, when the at least one guest operating system <NUM> wants to control the first hardware input/output device <NUM>, the first hardware input/output device <NUM> may be controlled using the first hardware interface device <NUM>. For example, when the at least one guest operating system <NUM> wants to control the second hardware input/output device <NUM>, the second hardware input/output device <NUM> may be controlled using the second hardware interface device <NUM>.

For convenience of illustration, <FIG> illustrates only two hardware input/output devices <NUM> and <NUM> and two hardware interface devices <NUM> and <NUM>. However, example embodiments are not limited thereto, and the number of hardware input/output devices and hardware interface devices may be variously determined according to example embodiments.

Although not illustrated in detail, the virtualized system according to example embodiments may be implemented by combining the examples of <FIG> and <FIG>.

Referring to <FIG>, a virtualized system <NUM> may include a system-on-chip (SOC) <NUM>, a memory device <NUM>, a display device <NUM>, a touch panel <NUM>, a storage device <NUM>, a power management integrated circuit (PMIC) <NUM>, etc. The system-on-chip <NUM> may include a processor <NUM>, a hardware interface device (HWIF) <NUM>, a memory controller <NUM>, a performance controller (PFMC) <NUM>, a user interface (UI) controller <NUM>, a storage interface <NUM>, one or more intellectual properties (IP) <NUM>, a direct memory access device (DMA IP) <NUM> having a function of direct memory access (DMA), a power management unit (PMU) <NUM>, a clock management unit (CMU) <NUM>, etc. It will be understood that components of the virtualized system <NUM> are not limited to the components illustrated in <FIG>. For example, the virtualized system <NUM> may further include a hardware codec for processing image data, a security block, and/or the like.

The processor <NUM> may execute software (for example, an application program, an operating system (OS), and device drivers) for the virtualized system <NUM>. The processor <NUM> may execute the operating system which may be loaded into the memory device <NUM>. The processor may be implemented by one of processors <NUM>, <NUM>, or <NUM>. The processor <NUM> may execute various application programs to be driven on the operating system. The processor <NUM> may be provided as a homogeneous multi-core processor or a heterogeneous multi-core processor. A multi-core processor is a computing component including at least two independently drivable processors (hereinafter referred to as "cores" or "processor cores"). Each of the cores may independently read and execute program instructions.

The memory controller <NUM> may provide interfacing between the memory device <NUM> and the system-on-chip <NUM>. The memory controller <NUM> may access the memory device <NUM> according to a request from the processor <NUM>, the intellectual property <NUM> and/or the direct memory access device <NUM>. For example, the memory device <NUM> may be implemented as a DRAM, and then the memory controller <NUM> may be referred to as a DRAM controller.

An operating system or basic application programs may be loaded into the memory device <NUM> during a booting operation. For example, a hypervisor HPVS, a host operating system HOS and a guest operating system GOS stored in the storage device <NUM> may be loaded into the memory device <NUM> based on a booting sequence during booting of the virtualized system <NUM>. Thereafter, corresponding applications APPs may be loaded into the memory device <NUM> by the host operating system HOS and the guest operating system GOS.

The hardware interface device <NUM> may support a communication between the guest operating system GOS and a hardware input/output device. For example, the memory device <NUM>, the storage device <NUM>, the IP <NUM> and the direct memory access device <NUM> may correspond to the hardware input/output device.

The performance controller <NUM> may adjust operation parameters of the system-on-chip <NUM> according to a control request provided from a kernel of the operating system. For example, the performance controller <NUM> may adjust a level of dynamic voltage and frequency scaling (DVFS) to enhance the performance of the system-on-chip <NUM>.

The user interface controller <NUM> may control user input and output from user interface devices. For example, the user interface controller <NUM> may display a keyboard screen for inputting data to the display device <NUM> according to a control of the processor <NUM>. Alternatively, the user interface controller <NUM> may control the display device <NUM> to display data requested by a user. The user interface controller <NUM> may decode data provided from user input means, such as the touch panel <NUM>, into user input data.

The storage interface <NUM> may access the storage device <NUM> according to a request from the processor <NUM>. For example, the storage interface <NUM> may provide interfacing between the system-on-chip <NUM> and the storage device <NUM>. For example, data processed by the processor <NUM> may be stored in the storage device <NUM> through the storage interface <NUM>. Alternatively, data stored in the storage device <NUM> may be provided to the processor <NUM> through the storage interface <NUM>.

The storage device <NUM> may be provided as a storage medium of the virtualized system <NUM>. The storage device <NUM> may store application programs, an operating system image, and various types of data. The storage device <NUM> may be provided as a memory card (e.g., MMC, eMMC, SD, MicroSD, etc.). The storage device <NUM> may include a NAND-type flash memory with high-capacity storage capability. Alternatively, the storage device <NUM> may include a next-generation nonvolatile memory such as PRAM, MRAM, ReRAM, and FRAM or a NOR-type flash memory.

The direct memory access device <NUM> may be provided as a separate intellectual property component to increase processing speed of a multimedia or multimedia data. For example, the direct memory access device <NUM> may be provided as an intellectual property component to enhance processing performance of a text, audio, still images, animation, video, two-dimensional (2D) data or three-dimensional (3D) data.

A system interconnector <NUM> may be a system bus to provide an on-chip network in the system-on-chip (SoC). The system interconnector <NUM> may include, for example, a data bus, an address bus and a control bus. The data bus may be a data transfer path. A memory access path to the memory device <NUM> or the storage device <NUM> may also be provided. The address bus may provide an address exchange path between intellectual properties. The control bus may provide a path along which a control signal is transmitted between intellectual properties. However, a configuration of the system interconnector <NUM> is not limited to the above description, and the system interconnector <NUM> may further include arbitration means for efficient management.

In some example embodiments, the direct memory access device <NUM> may have or perform a function of direct memory access to the memory device <NUM>. The direct memory access represents a scheme to transfer data directly from one memory device to another memory device or directly between a memory device and an input/output device without passing through the processor <NUM>, which may be supported by an internal bus of the virtualized system <NUM>. Modes of the direct memory access may include a burst mode in which the direct memory access device <NUM> steals control of the internal bus from the processor <NUM> to transfer data all at once, a cycle steal mode in which the direct memory access device <NUM> accesses the memory device <NUM> while the processor <NUM> does not access the memory device <NUM>. The direct memory access may be performed without intervention of the processor <NUM>. Accordingly, performance of the virtualized system <NUM> may be improved or enhanced because the processor <NUM> may operate while the direct memory access is performed.

The virtualized system <NUM> may further include a memory management circuit that manages a core access of the processor <NUM> to the memory device <NUM> and a direct access of the direct memory access device <NUM> to the memory device <NUM>. The core access and the direct access may include a read operation to read data from the memory device <NUM> and a write operation to store data to the memory device <NUM>. The core access may be performed based on a core access request issued by the processor <NUM>, and the direct access may be performed based on a direct access request issued by the direct memory access device <NUM>. For example, an operation of running the guest operating system GOS may be monitored, a target guest operating system controlling the direct memory access device <NUM> may be rebooted based on a monitoring result of running the guest operating system GOS, and the memory management circuit may be controlled to block the direct access of the direct memory access device <NUM> to the memory device <NUM> based on a control of the hypervisor HPVS when the target guest operating system is rebooted. Thus, the direct access may be rapidly blocked and a memory crash may be efficiently prevented by controlling the memory management circuit to provide temporal isolation of the direct memory access device <NUM> when the target guest operating system controlling the direct memory access device <NUM> is rebooted.

<FIG> is a block diagram illustrating an autonomous driving device including a virtualized system according to an example embodiment.

Referring to <FIG>, an autonomous driving device <NUM> may include a driver (e.g., including circuitry) <NUM>, a sensor <NUM>, a storage <NUM>, a controller (e.g., including processing circuitry) <NUM> and a communication interface <NUM>.

The driver <NUM> may, for example, be a configuration for driving the autonomous driving device <NUM> and may include various circuitry. In a case that the autonomous driving device <NUM> is implemented as a vehicle, the driver <NUM> may include various circuitry and/or components, such as, for example, an engine/motor <NUM>, a steering unit <NUM>, a brake unit <NUM>, and the like.

The engine/motor <NUM> may include any combination of an internal combustion engine, an electric motor, a steam locomotive, and a stirling engine. For example, in a case that the autonomous driving device <NUM> is a gas-electric hybrid car, the engine/motor <NUM> may be a gasoline engine and an electric motor. For example, the engine/motor <NUM> may be configured to supply energy for the autonomous driving device <NUM> to drive on a predetermined driving route.

The steering unit <NUM> may be any combination of mechanisms included to control a direction of the autonomous driving device <NUM>. For example, when an obstacle is recognized while the autonomous driving device <NUM> is driving, the steering unit <NUM> may change the direction of the autonomous driving device <NUM>. In a case that the autonomous driving device <NUM> is a vehicle, the steering unit <NUM> may be configured to turn the steering wheel clockwise or counterclockwise, and change the direction of travel for the autonomous driving device <NUM> accordingly.

The brake unit <NUM> may be any combination of mechanisms included to decelerate the autonomous driving device <NUM>. For example, the brake unit <NUM> may use friction or induction to reduce a speed of wheels/tires. When an obstacle is recognized while the autonomous driving device <NUM> is driving, the brake unit <NUM> may be configured to decelerate or slow the autonomous driving device <NUM>.

The driver <NUM> may be a driver of the autonomous driving device <NUM> driving or traveling on the ground, but example embodiments are not limited thereto. The driver <NUM> may include a flight propulsion unit, a propeller, wings, etc., and may include a variety of vessel propulsion devices in accordance with various example embodiments.

The sensor <NUM> may include a number of sensors configured to sense information relating to a surrounding environment of the autonomous driving device <NUM>. For example, the sensor <NUM> may include at least one of an image sensor <NUM>, a depth camera <NUM>, a light detection and ranging (LIDAR) unit <NUM>, a radio detection and ranging (RADAR) unit <NUM>, an infrared sensor <NUM>, a global positioning system (GPS) <NUM>, a magnetic sensor <NUM>, and/or an accelerometer sensor <NUM>.

The image sensor <NUM> may be configured to capture an image of or other data related to an external object located outside of the autonomous driving device <NUM>. The captured image or other data related to the external device may be used as data for changing at least one of a velocity and direction of the autonomous driving device <NUM>. The image sensor <NUM> may include a sensor of various types, such as a charge coupled device (CCD) and a complementary metal oxide semiconductor (CMOS). In addition, the depth camera <NUM> may acquire a depth for determining a distance between the autonomous driving device <NUM> and an external object.

The LIDAR unit <NUM>, the RADAR unit <NUM> and the infrared sensor <NUM> may each include a sensor configured to output a particular signal and sense external objects in an environment in which the autonomous driving device <NUM> is located. For example, the LIDAR unit <NUM> may include a laser light source and/or laser scanner configured to radiate a laser, and a detector configured to detect reflection of the laser. The RADAR unit <NUM> may be a sensor configured to sense objects in the environment in which the autonomous driving device <NUM> is located, using a wireless signal. In addition, the RADAR unit <NUM> may be configured to sense speeds and/or directions of the objects. The infrared sensor <NUM> may be a sensor configured to sense external objects in an environment in which the autonomous driving device <NUM> is located using a light of a wavelength of an infrared area.

The GPS <NUM>, the magnetic sensor <NUM>, and the accelerometer sensor <NUM> may each include a sensor configured to acquire information relating to a velocity, direction, location, etc., of the autonomous driving device <NUM>. For example, information relating to a current state of the autonomous driving device <NUM> may be acquired and a possibility of collision with an external object, etc., may be identified and/or estimated. The GPS <NUM> may be configured to identify a location of the autonomous driving device <NUM> as a latitude, longitude and altitude data through signals communicated with a satellite, and the magnetic sensor <NUM> and the accelerometer sensor <NUM> may be configured to identify the current state of the autonomous driving device <NUM> according to momentum, acceleration and orientation of the autonomous driving device <NUM>.

The storage <NUM> may be configured to store data necessary for the controller <NUM> to execute various processing. For example, the storage <NUM> may be realized as an internal memory such as a read-only memory (ROM), a random access memory (RAM) and the like included in the controller <NUM>, and may be realized as a separate memory from the controller <NUM>. In this case, the storage <NUM> may be realized in the form of a memory embedded in the autonomous driving device <NUM>, or may be realized in the form of a memory that may be detachable from the autonomous driving device <NUM> according to the usage of data storage. For example, data for driving the autonomous driving device <NUM> is stored in a memory embedded in the autonomous driving device <NUM>, and data for an extension function of the autonomous driving device <NUM> may be stored in a memory that may be detached from the autonomous driving device <NUM>. The memory embedded in the autonomous driving device <NUM> may be realized in the form of a non-volatile memory, volatile memory, flash memory, hard disk drive (HDD), solid state drive (SDD), or the like, and the memory that may be detached from the autonomous driving device <NUM> may be realized in the form of a memory card (e.g., micro SD card, universal serial bus (USB) memory), an external memory that is connectable to a USB port (e.g. USB memory), and the like.

The communication interface <NUM> may include various communication circuitry and may be configured to facilitate communication between the autonomous driving device <NUM> and an external device. For example, the communication interface <NUM> may transmit and receive driving information of the autonomous driving device <NUM> to and from the external device. For example, the communication interface <NUM> may be configured to perform communication through various communication methods such as an Infrared (IR) communication, a Wireless Fidelity (WI-FI), Bluetooth, Zigbee, Beacon, near field communication (NFC), WAN, Ethernet, IEEE <NUM>, HDMI, USB, MHL, AES/EBU, Optical, Coaxial, and the like. In some example embodiments, the communication interface <NUM> may be configured to communicate driving information through a server. For example, the communication interface <NUM> may include a transceiver for performing wireless communication.

The controller <NUM> may include a RAM <NUM>, a ROM <NUM>, a central processing unit (CPU) <NUM>, a hardware interface device (HWIF) <NUM>, a plurality of intellectual properties (IPs) <NUM> and <NUM>, and a bus <NUM>. The RAM <NUM>, the ROM <NUM>, the CPU <NUM> and the hardware interface device <NUM> may be connected to each other through the bus <NUM>, or at least two components may be directly connected through direct signal lines. The controller <NUM> may be implemented as a system on chip (SOC).

The RAM <NUM> may be a memory for reading, from the storage <NUM>, various instructions, etc., related to driving of the autonomous driving device <NUM>. The ROM <NUM> may store a set of instructions for system booting. In response to a turn on command being input to the autonomous driving device <NUM> and power being supplied, the CPU <NUM> may copy an operating system stored in the storage <NUM> into the RAM <NUM> according to a command stored in the ROM <NUM>, and boot the system by executing the operating system. If booting is completed, the CPU <NUM> performs various operations by copying various types of application programs stored in the storage <NUM> into the RAM <NUM> and executing the application programs copied into the RAM <NUM>. The controller <NUM> may perform various operations using a module stored in the storage <NUM>.

According to an example embodiment, the CPU <NUM> provides a virtualization environment including a hypervisor, a host operating system and a guest operating system. For example, the CPU <NUM> may be implemented by one of processors <NUM>, <NUM>, or <NUM>. The hardware interface device <NUM> may support a communication between the guest operating system and a hardware input/output device (e.g., the IPs <NUM> and <NUM>), and the guest operating system may control the hardware input/output device using the hardware interface device <NUM>. Accordingly, the guest operating system may communicate with the hardware input/output device without passing through complex software layers for implementing the virtualization, the performance of the hardware input/output device may be maintained and the performance degradation may be prevented, and the compatibility and portability of the software may be guaranteed or ensured.

<FIG> is a diagram illustrating an example where a virtualized system according to an example embodiment is mounted on a vehicle.

Referring to <FIG>, a virtualized system <NUM> may be an advanced driver assistance system (ADAS), an autonomous driving system, or the like, that is included in (e.g., mounted on) a vehicle <NUM>.

The virtualized system <NUM> may include various circuitry and components configured to receive a video sequence including a stereo image, reflected waves (e.g., reflected electromagnetic waves), or reflected lights from a camera mounted in the vehicle <NUM> and determine an occurrence of various events associated with the vehicle <NUM>. The various events may include object detection, object tracking and scene segmentation. The virtualized system <NUM> may generate an output signal that includes a notification message that may be presented to an occupant (e.g., user) of the vehicle <NUM>, via one or more user interfaces of the vehicle <NUM>, based on a determined occurrence of one or more events. The virtualized system <NUM> may generate an output signal that causes a vehicle control system of the vehicle <NUM> to control one or more driving elements of the vehicle <NUM> to control the driving (e.g., driving trajectory) of the vehicle <NUM>, based on a determined occurrence of one or more events.

For example, the virtualized system <NUM> may detect a road <NUM> including a fixed pattern and another vehicle <NUM> moving according to time, by analyzing the at least one video sequence <NUM>. For example, the virtualized system <NUM> may determine occurrence of an event based on detection of the other vehicle <NUM>, by analyzing a location of the other vehicle <NUM> by analyzing a coordinate of the other vehicle <NUM> in the at least one video sequence <NUM>. The virtualized system <NUM> may further, based on the determination, generate an output signal that, when processed by a control system of the vehicle <NUM>, causes a particular notification message to be presented to an occupant of the vehicle <NUM> via a user interface of the vehicle <NUM> and/or causes driving of the vehicle <NUM> to be controlled to cause the vehicle <NUM> to be driven along a particular driving path (e.g., driving trajectory) through the surrounding environment (e.g., autonomous driving, driving the vehicle <NUM> as an autonomous vehicle, etc.).

In some example embodiments, the vehicle <NUM> may include any means of transportation, such as, for example, and without limitation, an automobile, a bus, a truck, a train, a bicycle, a motorcycle, or the like, providing a communication function, a data processing function, and/or a transportation function.

Embodiments of the inventive concept may be used on various vehicles even though the vehicles are implemented with different types of hardwares. This use of virtualization may reduce the cost of providing software upgrades and maintenance for a long period of time on vehicles used for a long time. Even if a performance degradation occurs, when a virtualized system according to an example embodiment is applied or employed, the compatibility and portability of the software may be guaranteed without the performance degradation, and devices that are not supported by the host operating system may be run on the guest operating system.

As will be appreciated by those skilled in the art, the inventive concept may be embodied as a system, method, computer program product, and/or a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. The computer readable program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus. The computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, the computer readable medium may be a non-transitory computer readable medium.

Embodiments of the inventive concept may be applied to various electronic devices and systems to which the virtualization environment is applied or employed. For example, embodiments of the inventive concept may be applied to systems such as a personal computer (PC), a server computer, a data center, a workstation, a mobile phone, a smart phone, a tablet computer, a laptop computer, a personal digital assistant (PDA), a portable multimedia player (PMP), a digital camera, a portable game console, a music player, a camcorder, a video player, a navigation device, a wearable device, an internet of things (IoT) device, an internet of everything (IoE) device, an e-book reader, a virtual reality (VR) device, an augmented reality (AR) device, a robotic device, a drone, an automotive, etc..

Claim 1:
A system for allowing multiple operating systems to be run on one physical device (<NUM>), the system (<NUM>) comprising:
a processor (<NUM>) configured to provide a function for a virtualization environment;
a host operating system ,OS, (<NUM>) configured to run on the virtualization environment;
at least one guest operating system (<NUM>) configured to run on at least one virtual machine (<NUM>, <NUM>) of the virtualization environment;
a hypervisor (<NUM>) configured to implement the virtualization environment using the function of the processor (<NUM>), and configured to generate and control the at least one virtual machine (<NUM>, <NUM>) of the virtualization environment;
at least one hardware input/output (I/O) device (<NUM>) comprising at least one of various physical hardware devices and controlled by the host operating system (<NUM>) and the at least one guest operating system (<NUM>); and
at least one hardware interface device (<NUM>) configured to support communication between the at least one guest operating system (<NUM>) and the at least one hardware input/output device (<NUM>), wherein the at least one guest operating system (<NUM>) comprises:
a guest virtualization driver (<NUM>) for performing an operation of the virtualization environment, and
wherein the at least one hardware input/output device (<NUM>) is controlled through the guest virtualization driver (<NUM>) and the at least one hardware interface device (<NUM>), and wherein the guest virtualization driver (<NUM>) is configured to provide an interrupt directly to the at least one hardware interface device (<NUM>) without being trapped by the hypervisor (<NUM>) to control the at least one hardware input/output device (<NUM>).