SYSTEM, NON-TRANSITORIAL, MACHINE-READY STORAGE MEDIUM AND VIRTUAL SERIAL INTERFACE METHOD

Abstract

A system (100, 300) that includes the following: a storage medium (113) for storing information indicating the address locations of virtual serial ports, wherein the virtual serial ports are connected to respective virtual machines (VMs) of a plurality of VMs; a hypervisor (106, 306) running on a host processor (112); and a platform controller (108, 308) that is separate from the hypervisor (106, 306) and the host processor (112) and has a separate physical processor in which the emulation of the virtual serial ports can be provided, wherein the platform controller (108, 308) is designed to: to provide virtual functions (VFs) (150) that are assigned to the respective VMs, wherein the virtual serial ports are connected to the respective VFs (150) and the VFs (150) correspond to virtual serial port controllers that control the communication of the virtual serial ports, and wherein the VFs (150) are configurable to different types of virtual serial port controllers that are connected to first-in-first-out (FIFO) buffers of different sizes, based on the information, to detect access to a first virtual serial port that is assigned to a first VM of the multitude of VMs, and Data is communicated between the first VM and another entity via the first virtual serial port.

Description

background

[0001] A computer system includes various electronic components, such as a processor, memory, persistent storage, a network interface controller, etc. Machine-readable instructions, including software programs and / or firmware programs, can be executed on the processor. A user, a program, or an electronic component can perform communication in the computer system via a serial interface. US 2020 / 0 050 574 A1 describes a USB device redirection in a virtual desktop infrastructure (VDI) by means of which, when implemented, a user can connect a USB device to their client terminal, causing the USB device to function as if it were connected to the server.US 2020 / 0 026 425 A1 describes systems and methods for managing access to storage devices in a distributed data storage environment, in particular for managing communication between a client computing device and storage target devices in a distributed storage system. US 10 191 864 B1 describes an I / O (input / output) adapter device that can present itself as a storage backend driver with an emulated storage backend driver interface to a corresponding storage frontend driver executed by an operating system running on a host device independent of a virtualization or non-virtualization environment. US 2019 / 0 205 282 A1 describes a hypervisor of a device that can receive information identifying a virtual machine to use a universal asynchronous receiver / transmitter (UART) of the device.It is an object of the invention to propose a system, a non-transitory, machine-readable storage medium, and a method with virtual serial interfaces. This object is achieved by an inventive system according to claim 1, an inventive, non-transitory, machine-readable storage medium according to claim 15, and an inventive method according to claim 18. Short description of the drawings

[0002] Some implementations of the present disclosure are described with reference to the following figures. Fig. is a block diagram of a system according to some examples. Fig. is a block diagram of a platform controller according to some examples. Fig. are block diagrams of memory address spaces according to some examples. Fig. is a block diagram of a system with further examples. Fig. is a block diagram of a storage medium that stores machine-readable instructions according to some examples. Fig. is a flowchart of a process according to some examples.

[0003] In the drawings, identical reference numbers indicate similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated to better illustrate the example shown. Detailed description

[0004] Examples of computer systems include: a desktop computer, a notebook computer, a tablet computer, a server computer, a smartphone, a wearable device (e.g., a smart watch, smart glasses, a head-mounted device, etc.), a gaming device, an Internet of Things (IoT) device, a printing system, a storage device, a communication hub, and so on.

[0005] A computer system may include one (or more) serial interfaces. A "serial interface" may refer to a communications interface over which data is communicated as a serial stream (e.g., a serial stream of bits). A program or electronic component within the computer system may interact with another entity (e.g., an entity external to the computer system) through the serial interface. Examples of programs may include an operating system (OS), an application program, another type of software program, a firmware program, or other machine-readable instructions.

[0006] In some examples, a serial port in a bare-metal machine may include a physical serial port provided by a chipset in the bare-metal machine. A bare-metal machine may refer to a computer system in which machine-readable instructions can be executed directly on a hardware processor without an intermediate virtualization layer. A bare-metal machine does not include virtual machines (VMs) (see further below).

[0007] The physical serial port may include a serial controller and a serial connector through which the serial controller can communicate data in a serial stream. The data can be transmitted from the serial controller to another device, or the data can be received by the serial controller from another device.

[0008] In other examples of a bare-metal machine, a serial interface may include a virtual serial interface, such as one implemented by a Baseboard Management Controller (BMC).

[0009] Other types of computer systems may implement virtualization, where multiple VMs may run within a computer system (such VMs are also considered to be hosted by the computer system). The VMs may share the physical resources (e.g., a processor, memory, persistent storage, a network interface controller, etc.) of the computer system. A "virtual machine" or "VM" may refer to a partition of a computer system in which machine-readable instructions (e.g., a guest operating system, an application program, etc.) may be executed while being isolated from machine-readable instructions executing in another VM. In some examples, a container may also be considered a VM.

[0010] A computer system that implements virtualization may also include a hypervisor, also known as a virtual machine monitor (VMM). The hypervisor (which contains machine-readable instructions) provides a virtualization layer between the VMs and the underlying hardware. The hypervisor can create VMs that run within the computer system, and the hypervisor can manage the execution of the VMs and the sharing of the computer system's physical resources among the VMs. The hypervisor can emulate the computer system's physical resources, allowing a VM to access the emulated physical resources, and the hypervisor can provide isolation between VMs.

[0011] A program running in a VM or a user interacting with the VM may attempt to communicate over a serial port. In other examples, a VM in a computer system may receive communication on a serial port.

[0012] In some examples, a hypervisor can emulate serial interfaces for the VMs in the computer system. The hypervisor prevents different VMs from accessing the same real or virtual serial interface, because allowing different VMs to access the same serial interface would violate the goal of isolation between the different VMs.

[0013] Hypervisor emulation of serial ports consumes physical resources of the computer system, including processor resources. In a computer system with a large number of VMs, serial port emulation can consume processor cycles, which can slow other computer system operations. Another example: A malware-infected VM or a malfunctioning VM can perform a large number of data communications over a serial port, which can cause the computer system to slow down if the hypervisor performs serial port emulation to process these data communications.

[0014] According to some implementations of the present disclosure, instead of emulating a serial port using a hypervisor that handles communication over the serial port by or with VMs, the emulation of a serial port may be offloaded to a platform controller separate from the hypervisor. A "platform controller" may refer to a controller that performs certain tasks in a computer system. In some examples, the platform controller is a bus device on a bus, such as a Peripheral Component Interconnect (PCI) bus. In other examples, the platform controller may be a bus device connected to another type of bus in a system. A "bus" refers to a communications link over which multiple devices can communicate with each other.

[0015] The platform controller is separate from the system's main processor, and the main processor can execute various machine-readable instructions of the system, such as VMs, an operating system, an application program, firmware (e.g., boot code, hardware initialization code, etc.), and so on. The platform controller can be dedicated to performing specific system tasks, including emulating serial interfaces as well as other tasks (e.g., power management tasks, thermal management tasks, system monitoring tasks, etc.). In some examples, the platform controller can be a separate system-on-chip coupled to the main processor. In more specialized examples, the platform controller can consist of an intelligent network interface controller (NIC) or be part of a BMC.The platform controller may have its own processing circuitry (separate from the main processor that runs the operating system and / or other program code of a computer system) and run its own firmware. A BMC is a specialized service processor that can monitor the physical state of a computer system using sensors and communicates with a management system via an independent out-of-band connection.

[0016] The BMC can also communicate with applications running at the operating system level through an input / output controller (IOCTL) interface driver, a representational state transfer (REST) ​​application program interface (API), or another system software proxy that facilitates communication between the BMC and applications. The BMC can have hardware-level access to hardware components in the computer system. The BMC can be capable of directly modifying the hardware components. The BMC can operate independently of the operating system of the computer system in which the BMC resides. The BMC can be located on the motherboard or main board of the computer system to be monitored.The fact that a BMC is mounted on a motherboard of the computer system being monitored or is otherwise connected or attached to the computer system being monitored does not prevent the BMC from being considered separate from a processing resource running the operating system. A BMC provides management functions for managing components of the computer system. Examples of BMC management functions may include one or a combination of the following: power control, thermal monitoring and control, fan control, system health monitoring, remote access to the computer system, remote reboot of the computer system, system setup, operating system image deployment and recovery, system security, etc.

[0017] In some examples, a BMC may provide so-called "lights-out" functionality for computer systems. The "lights-out" functionality may allow a user, such as a system administrator, to perform administrative operations on the computer system even if no operating system is installed on the computer system or is not functioning. Furthermore, in some examples, the BMC may be powered by auxiliary power (such as battery power or an auxiliary power rail); therefore, the computer system does not need to be turned on for the BMC to perform its operations. The services provided by the BMC may be considered "out-of-band" services because the operating system may not be running and, in some cases, the computer system may be turned off or not functioning properly (such as if the computer system is experiencing a bug or hardware failure).

[0018] The BMC may include a communications interface, such as a network interface, and / or a serial interface, through which an administrator or other entity can remotely communicate with the BMC. An out-of-band service may be provided by the BMC over a dedicated management channel (such as the communications interface) and is available regardless of whether the computer system is in a powered-on state. In some examples, the BMC is an example of the platform controller.

[0019] The platform controller provides a separate physical processor (separate from the system's main processor) in which serial port emulation can be securely deployed. This protects the platform controller against attacks that could compromise the main processor's operation, such as malware infecting a system and running on the main processor.

[0020] Offloading serial port emulation to the platform controller reduces the processor resource consumption by the hypervisor for performing communication over the VMs' serial port. In some examples, a portion of PCI memory is allocated to contain serial port register sets associated with the respective VMs, with each serial port register set containing registers accessed when performing communication over the serial port. Accesses to the registers in the PCI memory section can be detected by the platform controller.

[0021] Fig. is a block diagram of a system 100. The system 100 may include one or more computer systems.

[0022] The system 100 comprises n VMs (VM 1 to VM n in Fig. shown), where n ≥ 1. VMs may be started upon request by a user or other entity. System 100 may start with zero VMs, and additional VM(s) may be started upon request. Each VM includes a corresponding guest operating system. VM 1 includes a guest operating system 102-1, and VM n includes a guest operating system 102-n. Examples of the guest operating systems include a Linux operating system, a Windows operating system, and / or other types of operating systems. The various guest operating systems 102-1 through 102-n may be of the same type or different types. Each VM may also include a corresponding application program (or multiple application programs) executing within the VM. For example, VM 1 includes an application program 104-1 and VM n includes an application program 104-n. Note that before creating a VM, there is no guest operating system 102-i (i = 1 to n) and no application program 104-i.

[0023] The system 100 also includes a hypervisor 106 that creates the VMs, manages the execution of the VMs, emulates physical resources of the system 100 that the VMs can access, provides isolation between the VMs, and performs other virtualization tasks.

[0024] According to some implementations of the present disclosure, instead of emulating a serial port using hypervisor 106, serial port emulation may be offloaded to a platform controller 108 of system 100. In some examples, platform controller 108 is a bus device on a bus 110 of system 100. For example, bus 110 may be a PCIe bus. In other examples, bus 110 may be another type of bus or another type of communication structure.

[0025] The platform controller 108 may be implemented with any type of hardware processing circuitry, such as a microcontroller, a programmable integrated circuit (e.g., an application-specific integrated circuit or ASIC), a programmable gate array, a microprocessor, or other type of hardware processing circuitry.

[0026] In some examples, the platform controller 108 is separate and distinct from a processor (or processors) 112 of the system 100. A processor may be a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry.

[0027] Processor 112 is coupled to bus 110, either directly or through another device, such as a bridge device. Processor 112 executes machine-readable instructions of system 100, including hypervisor 106 and VMs, a host operating system (if present), and other programs (including software programs and / or firmware programs).

[0028] The processor 112 may be coupled to a system memory 113, which may include one or more memory devices for storing data and machine-readable instructions. A memory device may be a volatile memory device, such as a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, etc. Alternatively, a memory device may be a non-volatile memory device. Although not shown, the system memory 113 may include a memory controller, or alternatively, a memory controller may be coupled to the memory device(s) to control access to the data in the memory device(s).

[0029] Other devices may also be connected to bus 110, including a network interface controller (NIC) 130 and persistent storage 132. NIC 130 is capable of communicating over a network, allowing components of system 100, including VMs, to communicate with other devices over the network through NIC 130. In some examples, a physical serial interface may be connected to bus 110.

[0030] Persistent storage 132 may store data that persists even if power to system 100 or persistent storage 132 is interrupted. Persistent storage 132 may be implemented with one or more non-volatile storage devices. A non-volatile storage device may include a flash memory device, a disk-based storage device, etc.

[0031] In examples according to Fig. The serial interface emulation can be performed using PCI functions 114-1 through 114-n, which are provided by the platform controller 108. The hypervisor 106 can assign one (or more) PCI function to each VM. The PCI functions 114-1 through 114-n each contain virtual universal asynchronous receiver-transmitters (vUARTs) 128-1 through 128-n. A UART is a device for sending and receiving serial data. Instead of implementing physical UARTs, the vUARTs 128-1 through 128-n contained in PCI functions 114-1 through 114-n are provided by the platform controller 108.

[0032] Fig. shows further details of the platform controller 108 according to some examples. The platform controller 108 may have other implementations in other examples. In some examples, the PCI functions 114-1 through 114-n of Fig. implemented as virtual functions (VFs) 150-1 to 150-n (shown in Fig. compliant with PCIe Single Root I / O Virtualization (SR-IOV) as defined by a PCI Special Interest Group (SIG), which is a community that defines standards (including the SR-IOV specification) related to PCIe. Each VF 150-i contains a corresponding vUART 128-i. In the example of Fig. VF 150-1 is assigned to VM 1, VF 150-n is assigned to VM n, and so on. Each VF can support a unique and separate data path for I / O-related functions (e.g., serial port communication) within the PCIe hierarchy. The vUART 128-1 emulates a serial interface for VM 1, and the vUART 128-n emulates the serial interface for VM n.

[0033] In other examples, PCI functions 114-1 through 114-n may be Fig. be implemented as a different type of function.

[0034] In further examples, it is possible to assign multiple serial interfaces per VM. In such examples, a VM can have multiple VFs (containing corresponding vUARTs) assigned to it, where the multiple VFs represent different serial interfaces assigned to the VM.

[0035] SR-IOV allows a PCle device (e.g. a serial interface controlled by the platform controller 108 of Fig. implemented) to present itself to a host (e.g., system 100) as multiple different virtual devices. The PCIe device (e.g., platform controller 108) implements a PCIe Physical Function (PF) 152, which is divided into multiple VFs (e.g., 150-1 to 150-n in Fig. partitioned to share the resources of the PCIe device in a virtual environment.

[0036] The PF 152 provides control over the creation and allocation of VFs. The PF 152 contains an SR-IOV capability structure and manages the SR-IOV functionality. The PF 152 can be used like any other PCIe device in the System 100 by Fig. be detected, managed and manipulated.

[0037] The VFs 150-1 to 150-n share the underlying platform controller hardware and the PCIe interface to the PCI bus 110.

[0038] The platform controller 108 from Fig. further comprises a processor 154 and a memory 156. The processor 154 of Fig. serves to execute commands of the platform controller 108 in order to fulfill tasks of the platform controller 108.

[0039] In accordance with some implementations of the present disclosure, SR-IOV enables serial port activations by VMs to bypass an emulation layer in hypervisor 106. VFs according to SR-IOV are lightweight, so a large number of VFs can be implemented in platform controller 108. For example, if system 100 includes a large number of VMs, a correspondingly large number of VFs can be implemented on platform controller 108 to perform serial port emulation for the respective VMs.

[0040] An SR-IOV-capable device (e.g., platform controller 108) may be configured (e.g., by hypervisor 106 or another entity in system 100) to appear in the PCI memory space as multiple VFs, with each VF having its own PCI memory space. A PCI memory may refer to a portion of memory space in system 100 that contains structures (e.g., registers) that can be used by an entity (e.g., a VM or other entity) in system 100 to interact with a corresponding PCI device, such as one of VFs 150-1 through 150-n.

[0041] In some examples, each VF 150-1 through 150-n has a class code representing a serial interface controller to perform serial interface emulation. According to PCIe, a class code is a three-byte field in a function's configuration space header that identifies a functionality of the function. For example, a class code may include a base class subfield (e.g., one byte long), a subclass subfield (e.g., one byte long), and a programming interface subfield (e.g., one byte long). The base class subfield broadly classifies the type of functionality provided by the VF. The subclass subfield more specifically identifies the type of functionality provided by the VF. The programming interface subfield identifies the specific register-level interface (if any) of a VF so that device-independent software (e.g., a VM) can interact with the VF.

[0042] In certain examples, a class code value of 07h / 00h / 02h (e.g., according to the PCI Code and ID Assignment Specification of PCI-SIG) represents a 16550-compatible serial port controller. In hypervisor 106, instead of emulating the 16550-compatible serial port controller, each VM can be assigned its respective VF 150-i (i = 1 to n) at specific I / O space addresses.

[0043] The 16550-compatible serial port controller is an example of a serial port controller that has a 16-byte first-in, first-out (FIFO) buffer. In other examples, VFs 150-1 through 150-n can emulate a different type of serial port controller, such as the 16850-compatible serial port controller, which has a 128-byte FIFO buffer. For example, the class code for the 16850-compatible serial port controller is 07h / 00h / 05h.

[0044] In some examples, VM i (i = 1 to n) can identify, based on the Base Class subfield and the Subclass subfield together, that a VF 150-i (i = 1 to n) provides the functionality of a serial interface controller. The Programming Interface subfield can identify a register set for the serial interface (in Fig. represented as 116-i (i = 1 to n)) with which VM i can interact (e.g., write a specific value to a register of the serial port register set 116-i to perform communication over the serial port of VM i). The registers of each serial port register set 116-i are part of a corresponding vUART 128-i. The serial port register set 116-i in the corresponding vUART 128-i is mapped to a memory address space 118, specifically to PCI memory in memory address space 118. The memory address space 118 can be implemented with a number of memory devices in system 100, including system memory 113 of Fig. , registers in the platform controller 108, etc. The serial interface register sets 116-1 through 116-n include memory-mapped registers that are part of the memory address space 118.

[0045] In alternative examples, such as examples where functions 114-1 through 114-n are PFs, serial interface register sets 116-1 through 116-n may be part of an I / O address space.

[0046] The registers of each serial port 116-i register set include UART registers used for communication over the serial port. For example, the registers of serial port 116-i register set may include: a transmitter hold buffer / receiver buffer (for holding transmitted or received data during communication over the serial port), a divisor latch bytes register (which holds a value that determines a communication data rate), and other registers.

[0047] Implementing the serial interface register sets 116-1 through 116-n in memory address space may be more efficient than implementing the serial interface register sets in I / O space (e.g., in implementations where SR-IOV is not used) because I / O space accesses to registers may slow the operation of the processor 112.

[0048] Memory addresses of memory address space 118 may be mapped to a memory controller and / or a PCIe controller. The memory controller is connected to a memory device (or alternatively, to multiple memory devices). A memory device may be a volatile memory device (e.g., a dynamic random access memory or DRAM device, a static random access memory or SRAM device, etc.). Alternatively, a memory device may include a non-volatile memory device (e.g., a flash memory device, etc.). A PCIe controller is connected to a PCIe device. A PCIe device may support memory accesses, but they may not actually access memory devices such as DRAMs or SRAMs. Instead, a PCIe device may access memory-mapped registers that are part of memory address space 118.

[0049] In some examples, the starting address (or base address) of the PCI memory space for each set of serial port registers 116-i is based on a memory address contained in a PCI base address register (BAR) 120 located in PCI configuration space. The PCI BAR 120 is contained in PF 152, as shown in Fig. shown. PCI defines multiple BARs that can be used to hold different memory addresses for a PCI device or function.

[0050] The base addresses 160-1 to 160-n of the PCI memory areas containing the respective serial port register sets 116-1 to 116-n are derived based on the memory address contained in BAR 120. The hypervisor 106 writes the memory address to BAR 120. The memory address contained in BAR 120 defines a chunk of PCI memory space to be evenly partitioned among VFs 150-1 to 150-n. The defined chunk of PCI memory space has a size BARSIZE. Each VF is assigned a portion of the PCI memory space chunk of size BARSIZE / n. The base address 160-i of the PCI memory containing the serial port register set 116-i is calculated based on the VF number of VF 150-i in conjunction with BAR 120.

[0051] A serial interface device driver (or other program) located in a VM can access the PCI memory area of ​​the corresponding VF. As described in Fig. As shown, several serial port device drivers 122-1 to 122-n are included in the respective guest operating systems 102-1 to 102-n.

[0052] In some examples, a guest operating system 102-i in VM i may include an application programming interface (API) that allows the device driver for the serial port 122-i in VM i to access the PCI memory space of the VF 150-i.

[0053] After SR-IOV has been enabled in the PF 152 of the platform controller 108, the VF instances 150-i are available for enumeration by the configuration software running on the processor 112 and can be addressed by bus, device, and function. The configuration software, which in some examples is the hypervisor 106, can then configure the desired number of VF instances 150-i from those supported by the PF 152 and allocate the resources accordingly (i.e., allocate a portion of the memory space 118 for the VF instances 150-i by programming the BAR 120). Once completed, the serial interface register sets 116-i are addressable by the processor 112.

[0054] The serial port driver 122-i in the guest operating system 102-i is capable of querying the hypervisor 106 to obtain the corresponding base address 160-i of the serial port register set, which the serial port driver 122-i accesses. This allows the serial port device driver 122-i in the guest operating system 102-i to perform communication over the serial port using the register set 116-i.

[0055] In examples where the guest operating system 102-i is unable to automatically detect PCI serial ports (e.g., the guest operating system 102-i is unable to detect the base class / subclass / programming interface values ​​of a serial port controller discussed above), the serial port address may be provided to the guest operating system 102-i by other means. An example of a guest operating system that is unable to automatically detect PCI serial interfaces is the LINUX operating system. In some examples, the serial port address may be provided to such a guest operating system 102-i by including the address in a kernel command line used to boot the guest operating system 102-i.In other examples, other means may be used to make the serial port address available to the 102-i guest operating system.

[0056] Each vUART 128-i can include serial port write detection logic and / or serial port read detection logic. The serial port write detection logic can detect writes by VMs or other entities (internal or external to system 100) to register sets 116-1 through 116-n of the respective vUARTs 128-1 through 128-n. Writes to registers of serial port register sets 116-1 through 116-n can be performed as part of serial port communication. The serial port read detection logic is capable of detecting reads by VMs or other entities to serial port register sets 116-1 through 116-n.

[0057] Write and read operations are directed to a respective vUART 128-i. In response to a write or read operation, the serial interface write or read detection logic in the vUART 128-i can send an interrupt to the processor 154 ( Fig. in the platform controller 108, e.g., using a corresponding serial port indicator 124-i. The serial port indicator 124-i may indicate which of the registers of the serial port register set 116-i was written to or read from. The serial port indicator 124-i may include a signal, interrupt, command, or other indication related to communication or serial port operation. The serial port indicator 124-i may include information indicating which VF 150-i the serial port indicator 124-i is associated with and which register was written to.

[0058] In response to the serial port 124-i indication, machine-readable instructions (e.g., firmware) running on processor 154 may redirect the UART traffic or synthesize an appropriate response. In other examples, the vUART 128-i includes hardware that redirects the data or synthesizes a response under the orchestration of machine-readable instructions (e.g., firmware) running on processor 154. For example, data transmitted by serial port device driver 122-i may be intercepted by the vUART 128-i and placed directly into a circular buffer (or other memory structure) connected to VM i.

[0059] In other examples, instead of providing VFs in a platform controller to emulate serial ports, an ACPI (Advanced Configuration and Power Interface) table 210 is used, as in Fig. shown, is used to store address information for serial ports according to further implementations of the present disclosure. In some examples, the ACPI table 210 is a Fixed ACPI Description Table (FADT). The FADT contains various configuration details related to registers.

[0060] The ACPI table 210 is part of the memory address space 118 contained in the system memory 113. According to some implementations of the present disclosure, the ACPI table 210 contains a plurality of serial port address fields 212-1 through 212-n associated with the respective VMs 1 through n. The serial port address field 212-1 contains an address of a memory location containing a serial port register set 214-1 for the corresponding VM 1, the serial port address field 212-n contains an address of the memory location containing a serial port register set 214-n for the corresponding VM n, and so on. The serial port register sets 214-1 through 214-n are similar to the serial port register sets 116-1 through 116-n of Fig. and can each contain registers of the vUARTs 128-1 to 128-n, as in Fig. shown. Serial port register sets 214-1 through 214-n include memory-mapped registers (identified as area 216) that are part of memory address space 118.

[0061] The starting address of area 216 can be specified, for example, by an address contained in a BAR (not shown).

[0062] In some examples, the addresses of serial port register sets 214-1 to 214-n may be assigned by the hypervisor 106 ( Fig. . The hypervisor 106 can write the serial port addresses into the corresponding serial port address fields 212-1 through 212-n of the ACPI table sections.

[0063] In other examples, the addresses of serial port register sets 214-1 through 214-n may be assigned by another entity (e.g., a host operating system or a BIOS (Basic Input / Output System)).

[0064] Fig. is a block diagram of a system 300 according to further examples. System 300 includes a storage medium 302 for storing information about virtual serial ports 304 that specify address locations of virtual serial ports. The virtual serial ports are associated with the respective VMs.

[0065] The virtual serial port information 304 may contain the addresses of the serial port register sets 116-1 to 116-n ( Fig. that start from a memory address in a BAR (e.g. 120 in Fig. or derived from other sources. In the example of Fig. The virtual serial port information may contain 304 addresses in the serial port address fields of the ACPI table 212-1 to 212-n, where these addresses refer to the serial port register sets 214-1 to 214-n in Fig. The serial port register sets 116-1 through 116-n or 214-1 through 214-n can be part of a memory address space or an I / O address space.

[0066] The system 300 includes a hypervisor 306 and a controller 308 (e.g., platform controller 108) separate from the hypervisor 306 to perform various tasks. The tasks of the controller 308 include a virtual serial port access detection task 310 to detect access to a first virtual serial port associated with a first VM based on information about the virtual serial port 304.

[0067] The tasks also include a serial port communication task 312 to communicate data between the first VM and another entity through the first virtual serial port.

[0068] In some examples, detecting access to the first virtual serial port includes detecting a write to a register associated with the first virtual serial port.

[0069] In some examples, the virtual serial interfaces are connected to corresponding VFs assigned to the respective VMs, where the VFs are implemented on the controller. The VFs can correspond to virtual serial port controllers (e.g., the vUARTs 128-1 through 128-n described in the Fig. shown) that control virtual serial port communication. In some examples, the VFs are configurable for different types of virtual serial port controllers connected to FIFO buffers of different sizes.

[0070] Fig. is a block diagram of a non-transitory machine-readable or computer-readable storage medium 400 having machine-readable instructions stored thereon that, when executed, cause a controller to perform certain tasks.

[0071] The machine-readable instructions include instructions for accessing information via virtual serial ports (402) to access information specifying address locations of virtual serial port register sets, where the virtual serial ports are associated with corresponding VMs.

[0072] The machine-readable instructions also include virtual serial port register write detection instructions 404 to detect a write of a register in a virtual serial port register set associated with a first VM based on the information.

[0073] The machine-readable instructions also include instructions for communicating via the virtual serial port 406 to, in response to the detection, communicate data between the first VM and another entity via the virtual serial port associated with the first VM without performing emulation of the serial port by a hypervisor.

[0074] Fig. is a flowchart of an example process 500 according to some examples.

[0075] The process 500 includes storing (at 502) information indicating the address locations of the virtual serial ports, where the virtual serial ports are associated with the respective VMs.

[0076] The process 500 further includes detecting (at 504) access to a first virtual serial port associated with a first VM based on the information by a controller coupled to a bus.

[0077] The process 500 further includes communicating (at 506) data between the first VM and another entity by the controller via the first virtual serial port.

[0078] The storage medium 400 from Fig.may include any one or a combination of the following: a semiconductor storage device, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; a magnetic disk, such as a hard disk, a floppy disk, and a removable disk; another magnetic medium, including tape; an optical medium, such as a compact disc (CD) or digital video disc (DVD); or another type of storage device. Note that the instructions discussed above may be provided on a single computer- or machine-readable storage medium, or alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system, possibly with multiple nodes.Such computer-readable or machine-readable storage medium or media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to each manufactured individual component or multiple components. The storage medium or media may be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded over a network for execution.

Claims

[1] A system (100, 300) comprising: a storage medium (113) for storing information indicating address locations of virtual serial ports, the virtual serial ports being connected to respective virtual machines (VMs) of a plurality of VMs; a hypervisor (106, 306) executing on a host processor (112); and a platform controller (108, 308) separate from the hypervisor (106, 306) and the host processor (112) and having a separate physical processor in which the emulation of the virtual serial ports can be provided, the platform controller (108, 308) being designed to: to provide virtual functions (VFs) (150) assigned to the respective VMs, wherein the virtual serial ports are connected to the respective VFs (150) and the VFs (150) correspond to virtual serial port controllers that control the communication of the virtual serial ports, and wherein the VFs (150) are configurable to different types of virtual serial port controllers connected to first-in-first-out buffers (FIFO) of different sizes, detect, based on the information, access to a first virtual serial port associated with a first VM of the plurality of VMs, and Communicate data between the first VM and another entity through the first virtual serial port. [2] The system (100, 300) of claim 1, wherein detecting access to the first virtual serial port comprises detecting a write to a register associated with the first virtual serial port. [3] The system (100, 300) of claim 2, wherein the information indicates the address locations of the respective register sets of the virtual serial ports. [4] The system (100, 300) of claim 3, wherein the respective register sets are located in an input / output (I / O) address space. [5] The system (100, 300) of claim 3, wherein the respective register sets are located in a memory address space. [6] The system (100, 300) of claim 1, wherein the information comprises a base address register (120) containing a memory address for deriving addresses for the virtual serial ports. [7] The system (100, 300) of claim 1, wherein the information comprises Advanced Configuration and Power Interface (ACPI) information. [8] The system (100, 300) of claim 1, wherein the platform controller (108, 308) is a Baseboard Management Controller (BMC). [9] The system (100, 300) of claim 8, wherein the serial port controllers include virtual universal asynchronous receiver-transmitters (vUARTs) (128). [10] The system (100, 300) of claim 9, wherein each VF (150) of the VFs (150) has a base class / subclass / programming interface configured to a serial port controller. [11] The system (100, 300) of claim 8, wherein the hypervisor (106, 306) is to assign the VFs (150) to the respective VMs. [12] The system (100, 300) of claim 1, wherein the hypervisor (106, 306) is to associate multiple virtual serial ports with a given VM of the plurality of VMs. [13] The system (100, 300) of claim 1, wherein the information is based on input from a kernel command line of a guest operating system (102) of a VM of the plurality of VMs. [14] The system (100, 300) of claim 1, further comprising a bus (110), wherein the platform controller (108, 308) comprises a bus device connected to the bus (110). [15] A non-transitory, machine-readable storage medium (400) containing instructions that, when executed, cause a platform controller (108, 308): access information indicating address locations of register sets of virtual serial ports, the virtual serial ports being associated with respective virtual machines (VMs) of a plurality of VMs, the register sets being associated with respective virtual functions (VFs) (150) provided by the platform controller (108, 308), and each VF (150) of the VFs (150) having a base class / subclass / programming interface set to a serial port controller; Detecting, based on the information, a write operation of a register in a register set of the virtual serial port associated with a first VM of the plurality of VMs; and in response to the detection, to communicate data between the first VM and another entity via the virtual serial port associated with the first VM without performing emulation of the serial port by a hypervisor (106, 306) executing on a host processor (112), wherein the platform controller (108, 308) is separate from the hypervisor (106, 306) and the host processor (112) and has a separate physical processor in which the emulation of the virtual serial ports can be provided. [16] The non-transitory machine-readable storage medium (400) of claim 15, wherein the information comprises a memory address in a base address register (BAR) (120), wherein the memory address in the BAR (120) can be used to derive addresses of the register sets. [17] The non-transitory machine-readable storage medium (400) of claim 15, wherein the VFs (150) are configurable to different types of virtual serial port controllers associated with first-in-first-out (FIFO) buffers of different sizes. [18] A method (500) comprising: Storing (502) information indicating address locations of virtual serial ports, the virtual serial ports being connected to respective virtual machines (VMs) of a plurality of VMs; Providing virtual functions (VFs) (150) assigned to the respective VMs by a platform controller (108, 308) which is separate from a hypervisor (106, 306) and from a host processor (112) on which the hypervisor (106, 306) is executed and has a separate physical processor in which the emulation of the virtual serial ports can be provided, wherein the virtual serial ports are connected to the respective VFs (150) and the VFs (150) correspond to virtual serial port controllers that control the communication of the virtual serial ports, and wherein the VFs (150) are configurable to different types of virtual serial port controllers connected to first-in-first-out buffers (FIFO) of different sizes, Detecting (504) access of a first virtual serial port associated with a first VM of the plurality of VMs based on the information of the platform controller (108, 308); and Communicating (506) data between the first VM and another entity by the platform controller (108, 308) via the first virtual serial port. [19] The method of claim 18, wherein the information indicates addresses of respective register sets of the virtual serial ports. [20] The method of claim 18, wherein each VF (150) of the VFs (150) has a base class / subclass / programming interface set to a serial port controller.

Images