DE102021101709A1

DE102021101709A1 - Virtuelle serielle schnittstellen für virtuelle maschinen

Info

Publication number: DE102021101709A1
Application number: DE102021101709.2A
Authority: DE
Inventors: Robert C. Elliott; Theodore F. Emerson
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-02-27
Filing date: 2021-01-26
Publication date: 2021-09-02
Also published as: US20210271500A1; CN113312141A; US11442767B2; CN113312141B

Abstract

In einigen Beispielen speichert ein Speichermedium Informationen, die Adressorte virtueller serieller Ports anzeigen, wobei die virtuellen seriellen Ports mit entsprechenden virtuellen Maschinen (VMs) verbunden sind. Ein Controller, der von einem Hypervisor getrennt ist, soll auf der Grundlage der Informationen einen Zugriff auf einen ersten virtuellen seriellen Port erkennen, der einer ersten VM aus der Vielzahl von VMs zugeordnet ist, und Daten zwischen der ersten VM und einer anderen Entität über den ersten virtuellen seriellen Port kommunizieren.

Description

Hintergrund
Ein Computersystem umfasst verschiedene elektronische Komponenten, wie z. B. einen Prozessor, einen Speicher, einen persistenten Speicher, einen Netzwerkschnittstellen-Controller usw. Maschinenlesbare Anweisungen, einschließlich Software-Programme und/oder Firmware-Programme, können auf dem Prozessor ausgeführt werden. Ein Benutzer, ein Programm oder eine elektronische Komponente kann die Kommunikation im Computersystem über eine serielle Schnittstelle durchführen.
Figurenliste
Einige Implementierungen der vorliegenden Offenbarung werden mit Bezug auf die folgenden Figuren beschrieben.

ist ein Blockdiagramm eines Systems gemäß einiger Beispiele.
ist ein Blockdiagramm einer Plattformsteuerung gemäß einiger Beispiele.
sind Blockdiagramme von Speicheradressräumen gemäß einiger Beispiele.
ist ein Blockdiagramm eines Systems nach weiteren Beispielen.
ist ein Blockdiagramm eines Speichermediums, das maschinenlesbare Anweisungen gemäß einigen Beispielen speichert.
ist ein Flussdiagramm eines Prozesses gemäß einiger Beispiele.

In den Zeichnungen bezeichnen identische Referenznummern ähnliche, aber nicht notwendigerweise identische, Elemente. Die Abbildungen sind nicht notwendigerweise maßstabsgetreu, und die Größe einiger Teile kann zur besseren Veranschaulichung des gezeigten Beispiels übertrieben sein. Darüber hinaus bieten die Zeichnungen Beispiele und/oder Implementierungen, die mit der Beschreibung übereinstimmen; die Beschreibung ist jedoch nicht auf die in den Zeichnungen dargestellten Beispiele und/oder Implementierungen beschränkt.
Detaillierte Beschreibung
In der vorliegenden Offenlegung schließt die Verwendung des Begriffs „ein“, „ein“ oder „die“ auch die Pluralformen ein, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Auch der Begriff „beinhaltet“, „einschließlich“, „umfasst“, „mit“, „haben“ oder „mit“, wenn er in dieser Offenbarung verwendet wird, spezifiziert das Vorhandensein der angegebenen Elemente, schließt aber das Vorhandensein oder die Zugabe anderer Elemente nicht aus.
Beispiele für Computersysteme sind: ein Desktop-Computer, ein Notebook, ein Tablet-Computer, ein Server-Computer, ein Smartphone, ein tragbares Gerät (z. B. eine intelligente Uhr, eine intelligente Brille, ein am Kopf getragenes Gerät usw.), ein Spielgerät, ein Internet-of-Things (IoT)-Gerät, ein Drucksystem, ein Speichergerät, ein Kommunikationsknoten und so weiter.
Ein Computersystem kann eine serielle Schnittstelle (oder mehrere serielle Schnittstellen) enthalten. Eine „serielle Schnittstelle“ kann sich auf eine Kommunikationsschnittstelle beziehen, über die Daten als serieller Strom (z. B. serieller Strom von Bits) kommuniziert werden. Ein Programm oder eine elektronische Komponente im Computersystem kann über die serielle Schnittstelle mit einer anderen Einheit (z. B. einer Einheit außerhalb des Computersystems) interagieren. Beispiele für Programme können ein Betriebssystem (OS), ein Anwendungsprogramm, eine andere Art von Softwareprogramm, ein Firmware-Programm oder andere maschinenlesbare Anweisungen sein.
In einigen Beispielen kann ein serieller Anschluss in einer Bare-Metal-Maschine einen physischen seriellen Anschluss umfassen, der von einem Chipsatz in der Bare-Metal-Maschine bereitgestellt wird. Ein Bare-Metal-Rechner kann sich auf ein Computersystem beziehen, in dem maschinenlesbare Anweisungen direkt auf einem Hardware-Prozessor ohne eine dazwischenliegende Virtualisierungsschicht ausgeführt werden können. Ein Bare-Metal-Rechner umfasst keine virtuellen Maschinen (VMs) (siehe weiter unten).
Der physikalische serielle Anschluss kann einen seriellen Controller und einen seriellen Anschlussstecker enthalten, über den der serielle Controller eine Kommunikation von Daten in einem seriellen Strom herstellen kann. Die Daten können von dem seriellen Controller an eine andere Einheit übertragen werden, oder die Daten können von dem seriellen Controller von einer anderen Einheit empfangen werden.
In anderen Beispielen einer Bare-Metal-Maschine kann eine serielle Schnittstelle eine virtuelle serielle Schnittstelle umfassen, wie sie beispielsweise von einem Baseboard Management Controller (BMC) implementiert wird.
Andere Arten von Computersystemen können eine Virtualisierung implementieren, bei der mehrere VMs in einem Computersystem ausgeführt werden können (solche VMs werden auch als vom Computersystem gehostet betrachtet). Die VMs können sich die physischen Ressourcen (z. B. einen Prozessor, einen Speicher, einen persistenten Speicher, einen Netzwerkschnittstellen-Controller usw.) des Computersystems teilen. Eine „virtuelle Maschine“ oder „VM“ kann sich auf eine Partition eines Computersystems beziehen, in der maschinenlesbare Anweisungen (z. B. ein Gastbetriebssystem, ein Anwendungsprogramm usw.) ausgeführt werden können, während sie von maschinenlesbaren Anweisungen, die in einer anderen VM ausgeführt werden, isoliert sind. In einigen Beispielen kann ein Container auch als VM betrachtet werden.
Ein Computersystem, das Virtualisierung implementiert, kann auch einen Hypervisor enthalten, der auch als Virtual Machine Monitor (VMM) bezeichnet wird. Der Hypervisor (der maschinenlesbare Anweisungen enthält) stellt eine Virtualisierungsschicht zwischen den VMs und der zugrunde liegenden Hardware bereit. Der Hypervisor kann VMs erstellen, die im Computersystem ausgeführt werden, und der Hypervisor kann die Ausführung der VMs und die gemeinsame Nutzung der physischen Ressourcen des Computersystems durch die VMs verwalten. Der Hypervisor kann die physischen Ressourcen des Computersystems emulieren, so dass eine VM auf die emulierten physischen Ressourcen zugreifen kann, und der Hypervisor kann eine Isolierung zwischen VMs bereitstellen.
Ein Programm, das in einer VM ausgeführt wird, oder ein Benutzer, der mit der VM interagiert, kann versuchen, eine Kommunikation über eine serielle Schnittstelle durchzuführen. In anderen Beispielen kann eine VM in einem Computersystem eine Kommunikation an einer seriellen Schnittstelle empfangen.
In einigen Beispielen kann ein Hypervisor serielle Schnittstellen für die VMs im Computersystem emulieren. Der Hypervisor verhindert, dass verschiedene VMs auf dieselbe reale oder virtuelle serielle Schnittstelle zugreifen, da der Zugriff verschiedener VMs auf dieselbe serielle Schnittstelle das Ziel der Isolation zwischen den verschiedenen VMs verletzen würde.
Die Emulation serieller Ports durch den Hypervisor verbraucht physische Ressourcen des Computersystems, einschließlich Prozessorressourcen. In einem Computersystem mit einer großen Anzahl von VMs kann die Emulation serieller Ports Zyklen eines Prozessors verbrauchen, wodurch andere Operationen des Computersystems verlangsamt werden können. Ein weiteres Beispiel: Eine mit Malware infizierte VM oder eine VM, die nicht richtig funktioniert, kann eine große Anzahl von Datenkommunikationen über einen seriellen Port durchführen, was zu einer Verlangsamung des Computersystems führen kann, wenn der Hypervisor eine Emulation des seriellen Ports durchführt, um diese Datenkommunikationen zu verarbeiten.
Gemäß einigen Implementierungen der vorliegenden Offenlegung kann die Emulation eines seriellen Ports anstelle der Emulation eines seriellen Ports unter Verwendung eines Hypervisors, der die Kommunikation über den seriellen Port durch oder mit VMs abwickelt, auf einen Plattform-Controller ausgelagert werden, der vom Hypervisor getrennt ist. Ein „Plattform-Controller“ kann sich auf einen Controller beziehen, der bestimmte Aufgaben in einem Computersystem ausführt. In einigen Beispielen ist der Plattform-Controller ein Busgerät an einem Bus, z. B. einem Peripheral Component Interconnect (PCI)-Bus. In anderen Beispielen kann der Plattform-Controller ein Bus-Gerät sein, das an einen anderen Bustyp in einem System angeschlossen ist. Ein „Bus“ bezieht sich auf eine Kommunikationsverbindung, über die mehrere Geräte miteinander kommunizieren können.
Der Plattform-Controller ist vom Hauptprozessor des Systems getrennt, wobei der Hauptprozessor verschiedene maschinenlesbare Anweisungen des Systems ausführen kann, z. B. VMs, ein Betriebssystem, ein Anwendungsprogramm, Firmware (z. B. Boot-Code, Hardware-Initialisierungscode usw.) und so weiter. Der Plattform-Controller kann dazu bestimmt sein, bestimmte Aufgaben des Systems auszuführen, einschließlich der Emulation serieller Schnittstellen sowie anderer Aufgaben (z. B. Energieverwaltungsaufgaben, Wärmemanagementaufgaben, Systemüberwachungsaufgaben usw.). In einigen Beispielen kann der Plattform-Controller ein separater System-on-Chip sein, der mit dem Hauptprozessor gekoppelt ist. In spezielleren Beispielen kann der Plattform-Controller aus einem intelligenten Netzwerk-Schnittstellen-Controller (NIC) bestehen oder Teil eines BMC sein. Der Plattform-Controller kann über einen eigenen Verarbeitungsschaltkreis verfügen (der vom Hauptprozessor, der das Betriebssystem und/oder anderen Programmcode eines Computersystems ausführt, getrennt ist) und seine eigene Firmware ausführen. Ein BMC ist ein spezialisierter Serviceprozessor, der den physischen Zustand eines Computersystems mithilfe von Sensoren überwachen kann und über eine unabhängige Out-of-Band-Verbindung mit einem Managementsystem kommuniziert.
Die BMC kann auch mit Anwendungen kommunizieren, die auf Betriebssystemebene ausgeführt werden, und zwar über einen IOCTL-Schnittstellentreiber (Input/Output Controller), eine REST-Anwendungsprogrammschnittstelle (API) (Representational State Transfer) oder einen anderen Systemsoftware-Proxy, der die Kommunikation zwischen der BMC und Anwendungen erleichtert. Die BMC kann auf Hardwareebene Zugriff auf Hardwarekomponenten im Computersystem haben. Die BMC kann in der Lage sein, die Hardware-Komponenten direkt zu modifizieren. Die BMC kann unabhängig vom Betriebssystem des Computersystems arbeiten, in dem sich die BMC befindet. Die BMC kann sich auf dem Motherboard oder der Hauptplatine des zu überwachenden Computersystems befinden. Die Tatsache, dass eine BMC auf einer Hauptplatine des zu überwachenden Computersystems montiert oder anderweitig mit dem zu überwachenden Computersystem verbunden oder daran angebracht ist, verhindert nicht, dass die BMC als getrennt von einer Verarbeitungsressource betrachtet wird, die das Betriebssystem ausführt. Eine BMC verfügt über Verwaltungsfunktionen zur Verwaltung von Komponenten des Computersystems. Beispiele für Verwaltungsfunktionen des BMC können eine oder eine Kombination der folgenden Funktionen umfassen: Stromversorgungssteuerung, thermische Überwachung und Steuerung, Lüftersteuerung, Überwachung des Systemzustands, Fernzugriff auf das Computersystem, Fernneustart des Computersystems, Systemeinrichtung, Bereitstellung und Wiederherstellung von Betriebssystem-Images, Systemsicherheit usw.
In einigen Beispielen kann ein BMC sogenannte „Lights-Out“-Funktionalität für Computersysteme bereitstellen. Die „Lights-Out“-Funktionalität kann es einem Benutzer, z. B. einem Systemadministrator, ermöglichen, Verwaltungsvorgänge auf dem Computersystem durchzuführen, auch wenn kein Betriebssystem auf dem Computersystem installiert ist oder nicht funktioniert. Darüber hinaus kann das BMC in einigen Beispielen mit Hilfsenergie betrieben werden (z. B. mit Batteriestrom oder einer Hilfsstromschiene); daher muss das Computersystem nicht eingeschaltet sein, damit das BMC seine Operationen durchführen kann. Die von der BMC bereitgestellten Dienste können als „Out-of-Band“-Dienste betrachtet werden, da das Betriebssystem möglicherweise nicht läuft und in einigen Fällen das Computersystem ausgeschaltet ist oder nicht ordnungsgemäß funktioniert (z. B. wenn das Computersystem einen Fehler oder einen Hardwareausfall aufweist).
Die BMC kann eine Kommunikationsschnittstelle, wie z. B. eine Netzwerkschnittstelle, und/oder eine serielle Schnittstelle enthalten, über die ein Administrator oder eine andere Instanz aus der Ferne mit der BMC kommunizieren kann. Ein „Out-of-Band“-Dienst kann vom BMC über einen dedizierten Verwaltungskanal (z. B. die Kommunikationsschnittstelle) bereitgestellt werden und ist unabhängig davon verfügbar, ob sich das Computersystem in einem eingeschalteten Zustand befindet. In einigen Beispielen ist der BMC ein Beispiel für den Plattform-Controller.
Der Plattform-Controller bietet einen separaten physikalischen Prozessor (getrennt vom Hauptprozessor des Systems), in dem die Emulation der seriellen Schnittstelle auf sichere Weise bereitgestellt werden kann. So ist der Plattform-Controller gegen Angriffe geschützt, die den Betrieb des Hauptprozessors beeinträchtigen können, z. B. wenn Malware ein System infiziert und auf dem Hauptprozessor ausgeführt wird.
Das Auslagern der Emulation des seriellen Ports auf den Plattform-Controller reduziert den Ressourcenverbrauch des Prozessors durch den Hypervisor, um die Kommunikation über den seriellen Port von VMs durchzuführen. In einigen Beispielen wird ein Teil eines PCI-Speichers zugewiesen, um Registersätze für die serielle Schnittstelle zu enthalten, die den jeweiligen VMs zugeordnet sind, wobei jeder Registersatz für die serielle Schnittstelle Register enthält, auf die bei der Durchführung der Kommunikation über die serielle Schnittstelle zugegriffen wird. Zugriffe auf die Register im PCI-Speicherabschnitt können vom Plattform-Controller erkannt werden.
ist ein Blockdiagramm eines Systems 100. Das System 100 kann ein Computersystem oder mehrere Computersysteme umfassen.
Das System 100 umfasst n VMs (VM 1 bis VM n in dargestellt), wobei n ≥ 1 ist. VMs können auf Anforderung durch einen Benutzer oder eine andere Entität gestartet werden. Das System 100 kann mit null VMs starten, und zusätzliche VM(s) werden auf Anforderung gestartet. Jede VM enthält ein entsprechendes Gastbetriebssystem. VM 1 enthält ein Gastbetriebssystem 102-1, und VM n enthält ein Gastbetriebssystem 102-n. Beispiele für die Gast-Betriebssysteme sind ein Linux-Betriebssystem, ein WINDOWS-Betriebssystem und/oder andere Arten von Betriebssystemen. Die verschiedenen Gast-Betriebssysteme 102-1 bis 102-n können vom gleichen Typ oder von unterschiedlichen Typen sein. Jede VM kann auch ein entsprechendes Anwendungsprogramm (oder mehrere Anwendungsprogramme) enthalten, das in der VM ausgeführt wird. Zum Beispiel enthält VM 1 ein Anwendungsprogramm 104-1 und VM n enthält ein Anwendungsprogramm 104-n. Beachten Sie, dass vor der Erstellung einer VM kein Gastbetriebssystem 102-i (i = 1 bis n) und kein Anwendungsprogramm 104-i vorhanden ist.
Das System 100 enthält außerdem einen Hypervisor 106, der die VMs erstellt, die Ausführung der VMs verwaltet, physische Ressourcen des Systems 100 emuliert, auf die die VMs zugreifen können, für Isolierung zwischen den VMs sorgt und andere Virtualisierungsaufgaben durchführt.
Gemäß einigen Implementierungen der vorliegenden Offenbarung kann die Emulation eines seriellen Ports anstelle der Emulation eines seriellen Ports unter Verwendung des Hypervisors 106 auf einen Plattform-Controller 108 des Systems 100 ausgelagert werden. In einigen Beispielen ist der Plattform-Controller 108 ein Busgerät an einem Bus 110 des Systems 100. Zum Beispiel kann der Bus 110 ein PCIe-Bus sein. In anderen Beispielen kann der Bus 110 eine andere Art von Bus oder eine andere Art von Kommunikationsstruktur sein.
Der Plattform-Controller 108 kann mit jeder Art von Hardware-Verarbeitungsschaltung implementiert werden, z. B. mit einem Mikrocontroller, einem programmierbaren integrierten Schaltkreis (z. B. einem anwendungsspezifischen integrierten Schaltkreis oder ASIC-Baustein), einem programmierbaren Gate-Array, einem Mikroprozessor oder einer anderen Art von Hardware-V erarbeitungsschaltu ng.
In einigen Beispielen ist der Plattform-Controller 108 separat und getrennt von einem Prozessor (oder Prozessoren) 112 des Systems 100. Ein Prozessor kann ein Mikroprozessor, ein Kern eines Multi-Core-Mikroprozessors, ein Mikrocontroller, eine programmierbare integrierte Schaltung, ein programmierbares Gate-Array, ein digitaler Signalprozessor oder eine andere Hardware-Verarbeitungsschaltung sein.
Der Prozessor 112 ist mit dem Bus 110 gekoppelt, entweder direkt oder über ein anderes Gerät, wie z. B. ein Brückengerät. Der Prozessor 112 führt maschinenlesbare Anweisungen des Systems 100 aus, einschließlich des Hypervisors 106 und der VMs, eines Host-Betriebssystems (falls vorhanden) sowie anderer Programme (einschließlich Software-Programme und/oder Firmware-Programme).
Der Prozessor 112 kann mit einem Systemspeicher 113 gekoppelt sein, der eine Speichervorrichtung oder mehrere Speichervorrichtungen umfassen kann, um Daten und maschinenlesbare Anweisungen zu speichern. Eine Speichervorrichtung kann eine flüchtige Speichervorrichtung sein, wie z. B. ein dynamischer Direktzugriffsspeicher oder DRAM-Vorrichtung, ein statischer Direktzugriffsspeicher oder SRAM-Vorrichtung usw.). Alternativ kann eine Speichervorrichtung auch eine nichtflüchtige Speichervorrichtung sein. Obwohl nicht dargestellt, kann der Systemspeicher 113 einen Speichercontroller enthalten, oder alternativ ist ein Speichercontroller mit der/den Speichervorrichtung(en) verbunden, um den Zugriff auf die Daten in der/den Speichervorrichtung(en) zu steuern.
An den Bus 110 können auch andere Geräte angeschlossen werden, darunter ein Netzwerkschnittstellen-Controller (NIC) 130 und ein persistenter Speicher 132. Die NIC 130 ist in der Lage, über ein Netzwerk zu kommunizieren, so dass die Komponenten des Systems 100, einschließlich der VMs, mit anderen Einheiten über das Netzwerk durch die NIC 130 kommunizieren können. In einigen Beispielen kann eine physische serielle Schnittstelle mit dem Bus 110 verbunden sein.
Der persistente Speicher 132 kann Daten speichern, die auch dann bestehen bleiben, wenn die Stromversorgung des Systems 100 oder des persistenten Speichers 132 unterbrochen wird. Der persistente Speicher 132 kann mit einem nichtflüchtigen Speichergerät (oder mehreren nichtflüchtigen Speichergeräten) implementiert werden. Ein nichtflüchtiges Speichergerät kann ein Flash-Speichergerät, ein plattenbasiertes Speichergerät usw. umfassen.
In Beispielen gemäß kann die Emulation der seriellen Schnittstelle mit Hilfe der PCI-Funktionen 114-1 bis 114-n durchgeführt werden, die vom Plattform-Controller 108 bereitgestellt werden. Der Hypervisor 106 kann jeder VM eine PCI-Funktion (oder mehrere PCI-Funktionen) zuweisen. Die PCI-Funktionen 114-1 bis 114-n enthalten jeweils virtuelle universelle asynchrone Empfänger-Sender (vUARTs) 128-1 bis 128-n. Ein UART ist ein Gerät zum Senden und Empfangen von seriellen Daten. Anstatt physische UARTs zu implementieren, werden die in den PCI-Funktionen 114-1 bis 114-n enthaltenen vUARTs 128-1 bis 128-n vom Plattform-Controller 108 bereitgestellt.
zeigt weitere Details des Plattformcontrollers 108 gemäß einigen Beispielen. Der Plattform-Controller 108 kann in anderen Beispielen andere Implementierungen haben. In einigen Beispielen sind die PCI-Funktionen 114-1 bis 114-n von als virtuelle Funktionen (VFs) 150-1 bis 150-n implementiert (gezeigt in , die der PCIe Single Root I/O-Virtualisierung (SR-IOV) entsprechen, wie sie von einer PCI Special Interest Group (SIG) definiert wurde, die eine Gemeinschaft ist, die Standards (einschließlich der SR-IOV-Spezifikation) in Bezug auf PCle definiert. Jeder VF 150-i enthält einen entsprechenden vUART 128-i. Im Beispiel von ist der VF 150-1 der VM 1 zugeordnet, der VF 150-n ist der VM n zugeordnet und so weiter. Jede VF kann einen eindeutigen und separaten Datenpfad für I/O-bezogene Funktionen (z. B. serielle Portkommunikation) innerhalb der PCIe-Hierarchie unterstützen. Der vUART 128-1 emuliert eine serielle Schnittstelle für VM 1, und der vUART 128-n emuliert die serielle Schnittstelle für VM n.
In anderen Beispielen können die PCI-Funktionen 114-1 bis 114-n aus als eine andere Art von Funktion implementiert werden.
In weiteren Beispielen ist es möglich, mehrere serielle Schnittstellen pro VM zuzuordnen. In solchen Beispielen können einer VM mehrere VFs (die entsprechende vUARTs enthalten) zugeordnet sein, wobei die mehreren VFs unterschiedliche serielle Schnittstellen darstellen, die der VM zugeordnet sind.
SR-IOV ermöglicht es einem PCIe-Gerät (z. B. einer seriellen Schnittstelle, die durch den Plattform-Controller 108 von implementiert wird), sich einem Host (z. B. dem System 100) als mehrere unterschiedliche virtuelle Geräte zu präsentieren. Das PCIe-Gerät (z. B. der Plattform-Controller 108) implementiert eine PCle Physical Function (PF) 152, die in mehrere VFs (z. B. 150-1 bis 150-n in partitioniert ist, um die Ressourcen des PCIe-Geräts in einer virtuellen Umgebung gemeinsam zu nutzen.
Der PF 152 bietet die Kontrolle über die Erstellung und Zuweisung von VFs. Der PF 152 enthält eine SR-IOV-Fähigkeitsstruktur und verwaltet die SR-IOV-Funktionalität. Der PF 152 kann wie jedes andere PCIe-Gerät im System 100 von erkannt, verwaltet und manipuliert werden.
Die VFs 150-1 bis 150-n teilen sich die zugrunde liegende Hardware des Plattform-Controllers und die PCIe-Schnittstelle zum PCI-Bus 110.
Der Plattform-Controller 108 von umfasst ferner einen Prozessor 154 und einen Speicher 156. Der Prozessor 154 von dient dazu, Befehle der Plattformsteuerung 108 auszuführen, um Aufgaben der Plattformsteuerung 108 zu erfüllen.
In Übereinstimmung mit einigen Implementierungen der vorliegenden Offenlegung ermöglicht SR-IOV serielle Port-Aktivierungen durch VMs, um eine Emulationsschicht im Hypervisor 106 zu umgehen. VFs gemäß SR-IOV sind leichtgewichtig, sodass eine große Anzahl von VFs im Plattform-Controller 108 implementiert werden kann. Wenn das System 100 beispielsweise eine große Anzahl von VMs enthält, kann eine entsprechend große Anzahl von VFs auf dem Plattform-Controller 108 implementiert werden, um die Emulation des seriellen Ports für die jeweiligen VMs durchzuführen.
Ein SR-IOV-fähiges Gerät (z. B. der Plattform-Controller 108) kann so konfiguriert werden (z. B. durch den Hypervisor 106 oder eine andere Entität im System 100), dass es im PCI-Speicherbereich als mehrere VFs erscheint, wobei jede VF ihren eigenen PCI-Speicherbereich hat. Ein PCI-Speicher kann sich auf einen Teil des Speicherraums im System 100 beziehen, der Strukturen (z. B. Register) enthält, die von einer Entität (z. B. einer VM oder einer anderen Entität) im System 100 verwendet werden können, um mit einem entsprechenden PCI-Gerät zu interagieren, wie z. B. einer der VFs 150-1 bis 150-n.
In einigen Beispielen hat jede VF 150-1 bis 150-n zur Durchführung der Emulation einer seriellen Schnittstelle einen Klassencode, der einen Controller für eine serielle Schnittstelle darstellt. Gemäß PCle ist ein Klassencode ein Drei-Byte-Feld im Header des Konfigurationsraums einer Funktion, das eine Funktionalität der Funktion identifiziert. Ein Klassencode kann zum Beispiel ein Basisklassen-Unterfeld (z. B. ein Byte lang), ein Unterklassen-Unterfeld (z. B. ein Byte lang) und ein Programmierschnittstellen-Unterfeld (z. B. ein Byte lang) enthalten. Das Basisklassen-Unterfeld klassifiziert grob die Art der Funktionalität, die die VF bietet. Das Unterklassen-Unterfeld identifiziert spezifischer die Art der Funktionalität, die die VF bietet. Das Programmierschnittstellen-Unterfeld identifiziert die spezifische Schnittstelle auf Registerebene (falls vorhanden) einer VF, so dass eine geräteunabhängige Software (z. B. eine VM) mit der VF interagieren kann.
In bestimmten Beispielen repräsentiert ein Klassencodewert von 07h/00h/02h (z. B. gemäß der PCI Code and ID Assignment Specification der PCI-SIG) einen 16550-kompatiblen seriellen Port-Controller. Im Hypervisor 106 kann jeder VM statt der Emulation des 16550-kompatiblen seriellen Port-Controllers an bestimmten I/O-Space-Adressen ihre jeweilige VF 150-i (i = 1 bis n) zugewiesen werden.
Der 16550-kompatible serielle Port-Controller ist ein Beispiel für einen seriellen Port-Controller, der einen 16-Byte-First-in-First-out-Puffer (FIFO) hat. In anderen Beispielen können die VFs 150-1 bis 150-n einen anderen Typ von seriellem Port-Controller emulieren, z. B. den 16850-kompatiblen seriellen Port-Controller, der einen 128-Byte-FIFO-Puffer hat. Der Klassencode für den 16850-kompatiblen seriellen Port-Controller ist z. B. 07h/00h/05h.
In einigen Beispielen kann VM i (i = 1 bis n) anhand des Unterfeldes Basisklasse und des Unterfeldes Unterklasse zusammen erkennen, dass eine VF 150-i (i = 1 bis n) die Funktionalität eines Controllers für die serielle Schnittstelle bereitstellt. Das Programmierschnittstellen-Unterfeld kann einen Registersatz für die serielle Schnittstelle identifizieren (in als 116-i (i = 1 bis n) dargestellt), mit dem VM i interagieren kann (z. B. einen bestimmten Wert in ein Register des Registersatzes für die serielle Schnittstelle 116-i schreiben, um eine Kommunikation über die serielle Schnittstelle von VM i durchzuführen). Die Register jedes seriellen Port-Registersatzes 116-i sind Teil eines entsprechenden vUART 128-i. Der serielle Port-Registersatz 116-i im entsprechenden vUART 128-i wird auf einen Speicheradressraum 118 abgebildet, und zwar auf PCI-Speicher im Speicheradressraum 118. Der Speicheradressraum 118 kann mit einer Reihe von Speichergeräten im System 100 implementiert werden, einschließlich des Systemspeichers 113 aus , Registern im Plattform-Controller 108 usw. Die Registersätze der seriellen Schnittstelle 116-1 bis 116-n umfassen speicherabgebildete Register, die Teil des Speicheradressraums 118 sind.
In alternativen Beispielen, z. B. in Beispielen, in denen die Funktionen 114-1 bis 114-n PFs sind, können die Registersätze 116-1 bis 116-n der seriellen Schnittstelle Teil eines E/A-Adressraums sein.
Die Register jedes Registersatzes der seriellen Schnittstelle 116-i umfassen UART-Register, die für die Kommunikation über die serielle Schnittstelle verwendet werden. Die Register des Registersatzes für den seriellen Anschluss 116-i können beispielsweise Folgendes umfassen: einen Sender-Haltepuffer/Empfängerpuffer (zum Halten von gesendeten oder empfangenen Daten während einer Kommunikation über den seriellen Anschluss), ein Divisor-Latch-Bytes-Register (das einen Wert hält, der eine Kommunikationsdatenrate bestimmt) und andere Register.
Die Implementierung der Registersätze für die serielle Schnittstelle 116-1 bis 116-n im Speicheradressraum kann effizienter sein als die Implementierung der Registersätze für die serielle Schnittstelle im E/A-Raum (z. B. in Implementierungen, in denen SR-IOV nicht verwendet wird), da E/A-Raum-Zugriffe auf Register den Betrieb des Prozessors 112 verlangsamen können.
Speicheradressen des Speicheradressraums 118 können auf einen Speicher-Controller und/oder einen PCIe-Controller abgebildet werden. Der Speicher-Controller ist mit einem Speichergerät (oder alternativ mit mehreren Speichergeräten) verbunden. Ein Speichergerät kann ein flüchtiges Speichergerät sein (z. B. ein dynamischer Direktzugriffsspeicher oder DRAM-Gerät, ein statischer Direktzugriffsspeicher oder SRAM-Gerät usw.). Alternativ kann eine Speichervorrichtung eine nichtflüchtige Speichervorrichtung umfassen (z. B. eine Flash-Speichervorrichtung usw.). Ein PCIe-Controller ist mit einem PCIe-Gerät verbunden. Ein PCIe-Gerät kann Speicherzugriffe unterstützen, aber sie dürfen nicht wirklich auf Speichergeräte wie DRAMs oder SRAMs zugreifen. Stattdessen kann ein PCIe-Gerät auf speicherabbildende Register zugreifen, die Teil des Speicheradressraums 118 sind.
In einigen Beispielen basiert die Startadresse (oder Basisadresse) des PCI-Speicherraums für jeden Satz serieller Portregister 116-i auf einer Speicheradresse, die in einem PCI-Basisadressregister (BAR) 120 enthalten ist, das sich im PCI-Konfigurationsraum befindet. Das PCI-BAR 120 ist im PF 152 enthalten, wie in gezeigt. PCI definiert mehrere BARs, die verwendet werden können, um verschiedene Speicheradressen für ein PCI-Gerät oder eine Funktion zu halten.
Die Basisadressen 160-1 bis 160-n der PCI-Speicherbereiche, die die jeweiligen seriellen Port-Registersätze 116-1 bis 116-n enthalten, werden auf Basis der in der BAR 120 enthaltenen Speicheradresse abgeleitet. Der Hypervisor 106 schreibt die Speicheradresse in die BAR 120. Die in der BAR 120 enthaltene Speicheradresse definiert einen Chunk von PCI-Speicherplatz, der gleichmäßig auf die VFs 150-1 bis 150-n zu partitionieren ist. Der definierte Chunk des PCI-Speicherplatzes hat eine Größe BARSIZE. Jeder VF wird ein Teil des Chunks des PCI-Speicherplatzes der Größe BARSIZE/n zugewiesen. Die Basisadresse 160-i des PCI-Speichers, der den seriellen Port-Registersatz 116-i enthält, wird auf der Grundlage der VF-Nummer von VF 150-i in Verbindung mit der BAR 120 berechnet.
Ein Gerätetreiber für die serielle Schnittstelle (oder ein anderes Programm), der sich in einer VM befindet, kann auf den PCI-Speicherbereich der entsprechenden VF zugreifen. Wie in gezeigt, sind mehrere serielle Port-Gerätetreiber 122-1 bis 122-n in den jeweiligen Gastbetriebssystemen 102-1 bis 102-n enthalten.
In einigen Beispielen kann ein Gastbetriebssystem 102-i in VM i eine Anwendungsprogrammierschnittstelle (API) enthalten, die es dem Gerätetreiber für die serielle Schnittstelle 122-i in VM i ermöglicht, auf den PCI-Speicherbereich des VF 150-i zuzugreifen.
Nachdem SR-IOV im PF 152 des Plattform-Controllers 108 aktiviert wurde, stehen die VF-Instanzen 150-i für die Aufzählung durch die auf dem Prozessor 112 laufende Konfigurationssoftware zur Verfügung und können per Bus, Gerät und Funktion angesprochen werden. Die Konfigurationssoftware, bei der es sich in einigen Beispielen um den Hypervisor 106 handelt, kann dann die gewünschte Anzahl von VF-Instanzen 150-i aus den vom PF 152 unterstützten konfigurieren und die Ressourcen entsprechend zuweisen (d. h. einen Teil des Speicherplatzes 118 für die VF-Instanzen 150-i durch Programmierung der BAR 120 zuweisen). Nach Fertigstellung sind die Registersätze 116-i der seriellen Schnittstelle durch den Prozessor 112 adressierbar
Der Treiber für die serielle Schnittstelle 122-i im Gastbetriebssystem 102-i ist in der Lage, den Hypervisor 106 abzufragen, um die entsprechende Basisadresse 160-i des Registersatzes für die serielle Schnittstelle zu erhalten, auf die der Treiber für die serielle Schnittstelle 122-i zugreift. Dies ermöglicht es dem Gerätetreiber für den seriellen Anschluss 122-i im Gastbetriebssystem 102-i, die Kommunikation über den seriellen Anschluss mithilfe des Registersatzes 116-i durchzuführen.
In Beispielen, in denen das Gastbetriebssystem 102-i nicht in der Lage ist, serielle PCI-Ports automatisch zu erkennen (z. B. ist das Gastbetriebssystem 102-i nicht in der Lage, die oben besprochenen Werte für Basisklasse/Unterklasse/Programmierschnittstelle eines Controllers für serielle Ports zu erkennen), kann die Adresse für den seriellen Port dem Gastbetriebssystem 102-i auf andere Weise bereitgestellt werden. Ein Beispiel für ein Gastbetriebssystem, das nicht in der Lage ist, serielle PCI-Schnittstellen automatisch zu erkennen, ist das Betriebssystem LINUX. In einigen Beispielen kann die Adresse für die serielle Schnittstelle einem solchen Gastbetriebssystem 102-i zur Verfügung gestellt werden, indem die Adresse in eine Kernel-Befehlszeile aufgenommen wird, die zum Starten des Gastbetriebssystems 102-i verwendet wird. In anderen Beispielen können andere Möglichkeiten verwendet werden, um die Adresse für die serielle Schnittstelle dem Gastbetriebssystem 102-i zur Verfügung zu stellen.
Jeder vUART 128-i kann eine Logik zur Erkennung von Schreibvorgängen am seriellen Anschluss und/oder eine Logik zur Erkennung von Lesevorgängen am seriellen Anschluss enthalten. Die Logik zur Erkennung von Schreibvorgängen an der seriellen Schnittstelle kann Schreibvorgänge durch VMs oder andere Einheiten (intern oder extern des Systems 100) in den Registersätzen 116-1 bis 116-n der jeweiligen vUARTs 128-1 bis 128-n erkennen. Schreibvorgänge von Registern der seriellen Port-Registersätze 116-1 bis 116-n können als Teil der seriellen PortKommunikation durchgeführt werden. Die Logik zur Erkennung von Lesevorgängen an der seriellen Schnittstelle ist in der Lage, Lesevorgänge durch VMs oder andere Entitäten der Registersätze der seriellen Schnittstelle 116-1 bis 116-n zu erkennen.
Schreib- und Lesevorgänge werden an einen jeweiligen vUART 128-i geleitet. Als Reaktion auf einen Schreib- oder Lesevorgang kann die Logik zur Erkennung von Schreib- oder Lesevorgängen an der seriellen Schnittstelle im vUART 128-i einen Interrupt an den Prozessor 154 ( im Plattformcontroller 108 signalisieren, z. B. mithilfe einer entsprechenden Anzeige für die serielle Schnittstelle 124-i. Die serielle Port-Anzeige 124-i kann anzeigen, in welches der Register des seriellen Port-Registersatzes 116-i geschrieben oder aus welchem gelesen wurde. Die Anzeige der seriellen Schnittstelle 124-i kann ein Signal, eine Unterbrechung, einen Befehl oder eine andere Anzeige in Bezug auf die Kommunikation oder den Betrieb der seriellen Schnittstelle enthalten. Die Anzeige der seriellen Schnittstelle 124-i kann Informationen enthalten, die angeben, welcher VF 150-i die Anzeige der seriellen Schnittstelle 124-i zugeordnet ist und in welches Register geschrieben wurde.
Als Reaktion auf die Anzeige der seriellen Schnittstelle 124-i können maschinenlesbare Anweisungen (z. B. Firmware), die auf dem Prozessor 154 laufen, den UART-Verkehr umleiten oder eine geeignete Antwort synthetisieren. In anderen Beispielen enthält der vUART 128-i Hardware, die die Daten umleitet oder eine Antwort unter der Orchestrierung von maschinenlesbaren Anweisungen (z. B. Firmware) synthetisiert, die auf dem Prozessor 154 laufen. Beispielsweise können Daten, die vom seriellen Port-Gerätetreiber 122-i übertragen werden, vom vUART 128-i abgefangen und direkt in einen Ringspeicher (oder eine andere Speicherstruktur) abgelegt werden, der mit VM i verbunden ist.
In anderen Beispielen wird anstelle der Bereitstellung von VFs in einem Plattform-Controller zur Emulation serieller Ports eine ACPI-Tabelle 210 (Advanced Configuration and Power Interface), wie in gezeigt, zum Speichern von Adressinformationen für serielle Ports gemäß weiteren Implementierungen der vorliegenden Offenbarung verwendet. In einigen Beispielen ist die ACPI-Tabelle 210 eine Fixed ACPI Description Table (FADT). Die FADT enthält verschiedene Konfigurationsdetails im Zusammenhang mit Registern.
Die ACPI-Tabelle 210 ist Teil des im Systemspeicher 113 enthaltenen Speicheradressraums 118. Gemäß einigen Implementierungen der vorliegenden Offenbarung enthält die ACPI-Tabelle 210 mehrere serielle Port-Adressfelder 212-1 bis 212-n, die den jeweiligen VMs 1 bis n zugeordnet sind. Das serielle Port-Adressfeld 212-1 enthält eine Adresse einer Speicherstelle, die einen seriellen Port-Registersatz 214-1 für die entsprechende VM 1 enthält, das serielle Port-Adressfeld 212-n enthält eine Adresse der Speicherstelle, die einen seriellen Port-Registersatz 214-n für die entsprechende VM n enthält, und so weiter. Die seriellen Port-Registersätze 214-1 bis 214-n ähneln den seriellen Port-Registersätzen 116-1 bis 116-n von und können jeweils Register der vUARTs 128-1 bis 128-n enthalten, wie in gezeigt. Die Registersätze 214-1 bis 214-n des seriellen Anschlusses umfassen speicherabgebildete Register (identifiziert als Bereich 216), die Teil des Speicheradressraums 118 sind.
Die Startadresse des Bereichs 216 kann z. B. durch eine in einer BAR (nicht dargestellt) enthaltene Adresse angegeben werden.
In einigen Beispielen können die Adressen der seriellen Port-Registersätze 214-1 bis 214-n durch den Hypervisor 106 zugewiesen werden ( . Der Hypervisor 106 kann die Adressen der seriellen Ports in die entsprechenden seriellen Port-Adressfelder 212-1 bis 212-n der ACPI-Tabellenabschnitte schreiben.
In anderen Beispielen können die Adressen der Registersätze der seriellen Schnittstelle 214-1 bis 214-n von einer anderen Instanz zugewiesen werden (z. B. von einem Host-Betriebssystem oder einem BIOS (Basic Input/Output System)).
ist ein Blockdiagramm eines Systems 300 gemäß weiteren Beispielen. Das System 300 enthält ein Speichermedium 302 zum Speichern von Informationen über virtuelle serielle Schnittstellen 304, die Adressorte von virtuellen seriellen Schnittstellen angeben. Die virtuellen seriellen Ports sind den jeweiligen VMs zugeordnet.
Die virtuellen seriellen Portinformationen 304 können die Adressen der seriellen Portregistersätze 116-1 bis 116-n ( enthalten, die von einer Speicheradresse in einer BAR (z. B. 120 in oder an anderen Stellen abgeleitet werden können. Im Beispiel von können die virtuellen seriellen Portinformationen 304 Adressen in den seriellen Portadressfeldern der ACPI-Tabelle 212-1 bis 212-n enthalten, wobei sich diese Adressen auf die seriellen Portregistersätze 214-1 bis 214-n in beziehen. Die Serienport-Registersätze 116-1 bis 116-n oder 214-1 bis 214-n können Teil eines Speicheradressraums oder eines E/A-Adressraums sein.
Das System 300 umfasst einen Hypervisor 306 und einen Controller 308 (z. B. Plattform-Controller 108), der vom Hypervisor 306 getrennt ist, um verschiedene Aufgaben durchzuführen. Zu den Aufgaben des Controllers 308 gehört eine Aufgabe zur Erkennung des Zugriffs auf einen virtuellen seriellen Port 310, um auf der Grundlage der Informationen über den virtuellen seriellen Port 304 einen Zugriff auf einen ersten virtuellen seriellen Port zu erkennen, der einer ersten VM zugeordnet ist.
Zu den Aufgaben gehört außerdem eine Aufgabe zur Kommunikation über die serielle Schnittstelle 312, um Daten zwischen der ersten VM und einer anderen Entität über die erste virtuelle serielle Schnittstelle zu kommunizieren.
In einigen Beispielen umfasst die Erkennung des Zugriffs auf den ersten virtuellen seriellen Anschluss eine Erkennung eines Schreibvorgangs in ein Register, das dem ersten virtuellen seriellen Anschluss zugeordnet ist.
In einigen Beispielen sind die virtuellen seriellen Schnittstellen mit entsprechenden VFs verbunden, die den jeweiligen VMs zugeordnet sind, wobei die VFs auf dem Controller implementiert sind. Die VFs können virtuellen seriellen Port-Controllern entsprechen (z. B. den vUARTs 128-1 bis 128-n, die in den und gezeigt sind), die die Kommunikation der virtuellen seriellen Ports steuern. In einigen Beispielen sind die VFs für verschiedene Typen von Controllern für virtuelle serielle Ports konfigurierbar, die mit FIFO-Puffern unterschiedlicher Größe verbunden sind.
ist ein Blockdiagramm eines nicht-transitorischen maschinenlesbaren oder computerlesbaren Speichermediums 400, auf dem maschinenlesbare Befehle gespeichert sind, die bei Ausführung einen Controller veranlassen, bestimmte Aufgaben auszuführen.
Die maschinenlesbaren Anweisungen enthalten Anweisungen für den Zugriff auf Informationen über virtuelle serielle Ports (402), um auf Informationen zuzugreifen, die Adresspositionen von Registersätzen virtueller serieller Ports angeben, wobei die virtuellen seriellen Ports mit entsprechenden VMs verbunden sind.
Die maschinenlesbaren Anweisungen enthalten außerdem Anweisungen 404 zur Erkennung des Schreibens von Registern des virtuellen seriellen Ports, um basierend auf den Informationen ein Schreiben eines Registers in einem Registersatz des virtuellen seriellen Ports zu erkennen, der einer ersten VM zugeordnet ist.
Die maschinenlesbaren Anweisungen enthalten außerdem Anweisungen zur Kommunikation über den virtuellen seriellen Port 406, um als Reaktion auf die Erkennung Daten zwischen der ersten VM und einer anderen Entität über den virtuellen seriellen Port zu kommunizieren, der der ersten VM zugeordnet ist, ohne eine Emulation des seriellen Ports durch einen Hypervisor durchzuführen.
ist ein Flussdiagramm eines Beispielprozesses 500 gemäß einigen Beispielen.
Der Prozess 500 umfasst das Speichern (bei 502) von Informationen, die die Adressorte der virtuellen seriellen Schnittstellen anzeigen, wobei die virtuellen seriellen Schnittstellen den jeweiligen VMs zugeordnet sind.
Der Prozess 500 umfasst ferner das Erkennen (bei 504) eines Zugriffs auf einen ersten virtuellen seriellen Port, der einer ersten VM zugeordnet ist, basierend auf den Informationen durch einen Controller, der mit einem Bus verbunden ist.
Der Prozess 500 umfasst ferner die Kommunikation (bei 506) von Daten zwischen der ersten VM und einer anderen Entität durch den Controller über den ersten virtuellen seriellen Port.
Das Speichermedium 400 von kann eine beliebige oder eine Kombination der folgenden Elemente enthalten: eine Halbleiterspeichereinrichtung, wie z. B. einen dynamischen oder statischen Direktzugriffsspeicher (DRAM oder SRAM), einen löschbaren und programmierbaren Festwertspeicher (EPROM), einen elektrisch löschbaren und programmierbaren Festwertspeicher (EEPROM) und einen Flash-Speicher; eine Magnetplatte, wie z. B. eine Festplatte, eine Diskette und eine Wechselplatte; ein anderes magnetisches Medium, einschließlich eines Bandes; ein optisches Medium, wie z. B. eine Compact Disc (CD) oder eine digitale Videodisk (DVD); oder eine andere Art von Speichereinrichtung. Beachten Sie, dass die oben besprochenen Anweisungen auf einem einzigen computer- oder maschinenlesbaren Speichermedium bereitgestellt werden können, oder alternativ auf mehreren computer- oder maschinenlesbaren Speichermedien, die in einem großen System mit möglicherweise mehreren Knotenpunkten verteilt sind. Ein solches computerlesbares oder maschinenlesbares Speichermedium oder solche Speichermedien werden als Teil eines Artikels (oder Herstellungsartikels) betrachtet. Ein Artikel oder Herstellungsgegenstand kann sich auf jede hergestellte Einzelkomponente oder mehrere Komponenten beziehen. Das Speichermedium oder die Speichermedien können sich entweder in der Maschine befinden, auf der die maschinenlesbaren Anweisungen ausgeführt werden, oder an einem entfernten Standort, von dem maschinenlesbare Anweisungen über ein Netzwerk zur Ausführung heruntergeladen werden können.
In der vorstehenden Beschreibung sind zahlreiche Details aufgeführt, um ein Verständnis des hier offengelegten Gegenstands zu ermöglichen. Es können jedoch auch Implementierungen ohne einige dieser Details durchgeführt werden. Andere Implementierungen können Modifikationen und Variationen von den oben beschriebenen Details enthalten. Es ist beabsichtigt, dass die beigefügten Ansprüche solche Modifikationen und Variationen abdecken.

Claims

Ein System, das Folgendes umfasst: ein Speichermedium zum Speichern von Informationen, die Adressorte virtueller serieller Ports anzeigen, wobei die virtuellen seriellen Ports mit jeweiligen virtuellen Maschinen (VMs) einer Vielzahl von VMs verbunden sind; einen Hypervisor; und einen Controller, der vom Hypervisor getrennt ist, den Controller zu: auf der Grundlage der Informationen einen Zugriff auf einen ersten virtuellen seriellen Port zu erkennen, der einer ersten VM der Vielzahl von VMs zugeordnet ist, und Daten zwischen der ersten VM und einer anderen Entität über die erste virtuelle serielle Schnittstelle kommunizieren.
System nach Anspruch 1, wobei die Erkennung des Zugriffs auf den ersten virtuellen seriellen Anschluss eine Erkennung eines Schreibvorgangs in ein dem ersten virtuellen seriellen Anschluss zugeordnetes Register umfasst.
System nach Anspruch 2, wobei die Informationen die Adressorte der jeweiligen Registersätze der virtuellen seriellen Schnittstellen angeben.
System nach Anspruch 3, wobei die jeweiligen Registersätze in einem Eingabe/Ausgabe (E/A)-Adressraum liegen.
System nach Anspruch 3, wobei die jeweiligen Registersätze in einem Speicheradressraum liegen.
System nach Anspruch 1, wobei die Informationen ein Basisadressenregister umfassen, das eine Speicheradresse zur Ableitung von Adressen für die virtuellen seriellen Schnittstellen enthält.
System nach Anspruch 1, wobei die Informationen Advanced Configuration and Power Interface (ACPI)-Informationen umfassen.
System nach Anspruch 1, wobei die virtuellen seriellen Schnittstellen mit jeweiligen virtuellen Funktionen (VFs) verbunden sind, die den jeweiligen VMs zugeordnet sind, wobei die VFs auf dem Controller implementiert sind.
System nach Anspruch 8, wobei die VFs virtuellen seriellen Port-Controllern entsprechen, die die Kommunikation der virtuellen seriellen Ports steuern.
System nach Anspruch 9, wobei die VFs auf verschiedene Typen von Controllern für virtuelle serielle Ports konfigurierbar sind, die mit First-in-First-out-Puffern (FIFO) unterschiedlicher Größe verbunden sind.
System nach Anspruch 8, wobei der Hypervisor die jeweiligen VFs den jeweiligen VMs zuweisen soll.
System nach Anspruch 1, wobei der Hypervisor mehrere virtuelle serielle Ports mit einer gegebenen VM aus der Vielzahl von VMs assoziieren soll.
System nach Anspruch 1, wobei die Information auf einer Eingabe von einer Kernel-Befehlszeile eines Gastbetriebssystems einer VM aus der Vielzahl von VMs basiert.
System nach Anspruch 1, das ferner einen Bus umfasst, wobei der Controller ein mit dem Bus verbundenes Busgerät umfasst.
Ein nicht-transitorisches, maschinenlesbares Speichermedium, das Befehle enthält, die bei Ausführung eine Steuerung veranlassen: Zugriffsinformationen, die Adressorte von Registersätzen virtueller serieller Ports anzeigen, wobei die virtuellen seriellen Ports mit jeweiligen virtuellen Maschinen (VMs) einer Vielzahl von VMs verbunden sind; Erkennen, basierend auf der Information, eines Schreibvorgangs eines Registers in einem Registersatz des virtuellen seriellen Ports, der mit einer ersten VM der Vielzahl von VMs assoziiert ist; und als Reaktion auf die Erkennung, Daten zwischen der ersten VM und einer anderen Entität über den virtuellen seriellen Port, der der ersten VM zugeordnet ist, zu kommunizieren, ohne eine Emulation des seriellen Ports durch einen Hypervisor durchzuführen.
Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 15, wobei die Information eine Speicheradresse in einem Basisadressregister (BAR) umfasst, wobei die Speicheradresse in dem BAR zum Ableiten von Adressen der Registersätze verwendet werden kann.
Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 15, wobei die Registersätze mit jeweiligen virtuellen Funktionen (VFs) verbunden sind, die von der Steuerung bereitgestellt werden.
Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei jede VF der VFs eine Basisklasse/Unterklasse/Programmierschnittstelle hat, die auf einen seriellen Port-Controller eingestellt ist.
Ein Verfahren, das Folgendes umfasst: Speichern von Informationen, die Adressorte von virtuellen seriellen Ports anzeigen, wobei die virtuellen seriellen Ports mit jeweiligen virtuellen Maschinen (VMs) einer Vielzahl von VMs verbunden sind; Erkennen eines Zugriffs eines ersten virtuellen seriellen Ports, der einer ersten VM der Vielzahl von VMs zugeordnet ist, basierend auf der Information durch einen Controller, der mit einem Bus verbunden ist; und Kommunikation von Daten zwischen der ersten VM und einer anderen Entität durch den Controller über den ersten virtuellen seriellen Port.
Verfahren nach Anspruch 19, wobei die Informationen Adressen von jeweiligen Registersätzen der virtuellen seriellen Schnittstellen angeben.