DE112019003920T5

DE112019003920T5 - Sicherer zugriff auf speicher einer virtuellen maschine

Info

Publication number: DE112019003920T5
Application number: DE112019003920.2T
Authority: DE
Inventors: Ajay Kumar Gupta; Venkat Tammineedi; David Lim; Ashutosh Jha
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-03
Filing date: 2019-08-02
Publication date: 2021-05-20
Also published as: US20220413892A1; US11429419B2; US20200042341A1; WO2020028782A1; JP2021532495A; JP7384900B2; CN112740180B; CN112740180A

Abstract

In verschiedenen Beispielen wird ein Zugriff auf VM-Speicher durch Virtualisierungssoftware unter Verwendung einer vertrauenswürdigen Firmware eines Host-Controllers gesichert, um einen oder mehrere Befehle zum Lesen des Speichers einer VM und/oder der aus VM-Speicher gelesenen Daten zu validieren, um vor unberechtigtem Zugriff auf Daten in VM-Speicher zu schützen. Falls die Validierung fehlschlägt, kann die Firmware davon absehen, die Daten zu lesen und/oder der Virtualisierungssoftware Zugriff auf die Daten zu gewähren. Die Daten können einen Anforderungsbefehl von einer VM in Bezug auf ein Herstellen oder Ändern einer Verbindung zu einer anderen Entität, wie beispielsweise einer anderen Vorrichtung innerhalb oder außerhalb der Virtualisierungsumgebung, unter Verwendung des Host-Controllers beinhalten. Die Virtualisierungssoftware kann den Anforderungsbefehl dazu verwenden, die Verbindung zu erleichtern. Der Host-Controller kann ein eXtensible Host Controller Interface (xHCI) oder eine andere Art von Schnittstelle für die Verbindung bereitstellen.

Description

HINTERGRUND
Virtualisierung ermöglicht die gleichzeitige Ausführung mehrerer virtueller Maschinen bzw. Virtual Machines (VMs) - die häufig als Host für Betriebssystem-Instanzen (OSI) verwendet werden - innerhalb eines einzigen Host-Systems. Eine Standardschnittstelle (ohne Virtualisierung der Schnittstelle), die von einem Host-Controller dem Host-System präsentiert wird, kann eine Physical Function (PF)- oder Host-Controller-Schnittstelle beinhalten. Beispiele von Host-Controller-Schnittstellen beinhalten diejenigen, die für Universal Serial Bus (USB), Fire Wire, Bluetooth, Ethernet, Peripheral Component Interconnect (PCI) oder andere Kommunikationsarten verwendet werden. Beispielsweise kann ein eXtensible Host Controller Interface (xHCI) zur Unterstützung von USB-Kommunikation verwendet werden. Die Virtualisierung der Host-Controller-Schnittstelle ermöglicht es mehreren virtuellen Funktionen (VF), sich einen PF zu teilen. Um Hardware-Anforderungen zu minimieren, beinhaltet die physische Schnittstelle, die von einer VF dargestellt wird, typischerweise nur eine Teilmenge derjenigen, die von der entsprechenden PF dargestellt wird, und verlässt sich auf Virtualisierungssoftware, um Teile der VF-Schnittstelle zu emulieren, um die Lücken zu füllen.
Konventionell kann die Virtualisierungssoftware dazu verwendet werden, eine Verbindung zwischen einer VM und einer anderen Entität, die eine VF verwendet, wie beispielsweise eine andere Entität innerhalb des Host-Systems (z.B. eine andere VM) oder eine Entität außerhalb des Host-Systems (z.B. ein Hardware-Gerät) zu erleichtern. Zum Beispiel kann die Virtualisierungssoftware die VM dabei unterstützen, eine Verbindung unter Verwendung der VF herzustellen oder eine bestehende Verbindung unter Verwendung der VF zu ändern. Um die Verbindung zu erleichtern, kann die Virtualisierungssoftware Daten aus dem Speicher der VM lesen, die von der VM angeforderte Informationen anzeigen, wie z.B. Verbindungseigenschaften. Im Beispiel von xHCI kann es sich bei den Daten um Command Transfer Request Block (TRB)-Daten handeln, die dazu verwendet werden, Geräteeigenschaften eines neu angeschlossenen Geräts anzufordern. Dies stellt insofern ein Sicherheitsrisiko dar, als dass, wenn die Virtualisierungssoftware kompromittiert wird, es einem böswilligen Akteur möglich sein könnte, den jeder beliebigen VM zugewiesenen Speicher über die Host-Controller-Schnittstelle zu lesen. Beispielsweise könnte eine Komponente der Virtualisierungssoftware, die für die Zuordnung von VM-Speicher verantwortlich ist, die Zuordnung manipulieren, um auf nicht autorisierte Speicherplätze zuzugreifen.
KURZBESCHREIBUNG
Die Erfindung bezieht sich zum Teil auf die Sicherung des Zugriffs auf VM-Speicher durch Virtualisierungssoftware, um eine Verbindung zwischen einer VM und einer anderen Entität unter Verwendung einer VF zu ermöglichen. Im Gegensatz zu herkömmlichen Ansätzen kann eine vertrauenswürdige Firmware eines Host-Controllers einen oder mehrere Befehle zum Lesen des Speichers einer VM und/oder die aus dem VM-Speicher gelesenen Daten validieren, um vor einem unzulässigen Zugriff auf Daten in VM-Speicher zu schützen. Falls die Validierung fehlschlägt, kann die Firmware das Lesen der Daten unterlassen und/oder der Virtualisierungssoftware keinen Zugriff auf die Daten gewähren. Falls also die Virtualisierungssoftware kompromittiert wird, kann ein böswilliger Akteur daran gehindert werden, willkürlich auf VM-Speicher zuzugreifen.
Um die Daten zu lesen, können ein oder mehrere Verwalter virtueller Maschinen bzw. Virtual Machine Manager (VMMs) der Virtualisierungssoftware einen Lesebefehl an vertrauenswürdige Firmware des Host-Controllers senden, der zu lesende Speicherplätze angibt, um auf die Daten zuzugreifen. Die Firmware des Host-Controllers kann den Lesebefehl und/oder die aus VM-Speicher gelesenen Daten validieren. Beispielsweise kann die Firmware des Host-Controllers bestätigen, dass der Lesebefehl mit einem Türklingel-Ereignis bzw. Doorbell Event für den Befehlsring bzw. Command Ring einer entsprechenden VM übereinstimmt, bestätigen, dass sie vor dem Empfang des Lesebefehls ein Doorbell Event an den VMM gesendet hat, und/oder überprüfen, ob eine durch den Befehl angegebene Speichergröße gültig ist. Als weitere Beispiele kann die Firmware des Host-Controllers die Daten lesen und bestätigen, dass die Daten ein korrektes Format haben und/oder korrekte Informationen oder Parameter enthalten. Der Host-Controller kann dem VMM den Zugriff auf die Daten verweigern, wenn der Befehl und/oder die Daten nicht validiert sind (z.B. als ungültig eingestuft werden).
Figurenliste
Die vorliegenden Systeme und Verfahren für sicheren Zugriff auf Speicher einer virtuellen Maschine werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungsfiguren näher beschrieben, wobei:

1 ein Diagramm eines Beispiels einer Betriebsumgebung zur Validierung des Zugriffs von Virtualisierungssoftware auf Daten im Speicher ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
2 ein Ablaufdiagramm eines Beispiels eines Prozesses zum Validieren des Zugriffs von Virtualisierungssoftware auf Daten im Speicher ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
3 ein Ablaufdiagramm eines Beispiels eines Verfahrens zum Validieren von Daten, die im Ansprechen auf einen Lesebefehl von Virtualisierungssoftware aus VM-Speicher gelesen wurden, ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
4 ein Ablaufdiagramm eines Beispiels eines Verfahrens zum Validieren eines Befehls von Virtualisierungssoftware zum Lesen von VM-Speicher ist, gemäß einigen Ausführungsformen der Erfindung;
5 ist ein Ablaufdiagramm eines Beispiels eines Verfahrens für Virtualisierungssoftware zum Lesen von Daten aus VM-Speicher unter Verwendung einer Firmware des Host-Controllers ist, gemäß einigen Ausführungsformen der Erfindung; und
6 ein Blockdiagramm einer beispielhaften Computerumgebung ist, die zum Validieren eines Zugriffs von Virtualisierungssoftware auf Daten in Speicher geeignet ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung.

DETAILLIERTE BESCHREIBUNG
Es werden Systeme und Verfahren offenbart, die sich auf die Verwendung vertrauenswürdiger Firmware eines Host-Controllers beziehen, um einen oder mehrere Befehle zum Lesen des Speichers einer VM (z.B. Systemspeicher, der für eine VM dediziert oder ihr zugeordnet ist) und/oder die aus VM-Speicher gelesenen Daten zu validieren, um vor einem unzulässigen Zugriff auf Daten in Systemspeicher zu schützen. Infolgedessen kann dann, wenn Virtualisierungssoftware kompromittiert wird, ein böswilliger Akteur daran gehindert werden, willkürlich auf VM-Speicher zuzugreifen.
In verschiedenen Ausführungsformen können ein oder mehrere Virtual Machine Manager (VMM(s)) von Virtualisierungssoftware und eine virtuelle Funktion bzw. VF verwendet werden, um eine Verbindung zwischen einer VM und einer anderen Entität (z.B. einer externen VM, einem externen Gerät), wie beispielsweise einer anderen Entität innerhalb des Host-Systems (z.B. einer anderen VM) oder einer Entität außerhalb des Host-Systems, zu erleichtern. Der/die VMM(s) kann/können einen Hypervisor eines Hostsystems enthalten oder nicht. Um die Verbindung zu erleichtern, kann die VM eine Benachrichtigung von dem VMM bezüglich der Entität erhalten. Zum Beispiel kann ein Benutzer ein USB-Gerät an einen xHCI-Controller anschließen, und kann der xHCI-Controller den VMM über das neue Gerät benachrichtigen, der wiederum die entsprechende VM benachrichtigt. Als Reaktion auf die Benachrichtigung kann die VM einen für den VMM bestimmten Befehl bereitstellen, den sie als Daten in dem Speicher des zugrunde liegenden Systems oder Geräts speichert, das für die VM bestimmt ist. Um die Daten zu lesen, kann der VMM einen Lesebefehl an die vertrauenswürdige Firmware des Host-Controllers senden, der zu lesende Speicherplätze angibt, um auf die Daten zuzugreifen.
In einigen Aspekten der Erfindung kann die Firmware des Host-Controllers den Lesebefehl validieren. Zum Beispiel kann die Firmware des Host-Controllers bestätigen, dass der Lesebefehl mit einem Doorbell Event für einen Command Ring einer entsprechenden VM übereinstimmt. Als weiteres Beispiel kann die Firmware des Host-Controllers bestätigen, dass sie vor dem Empfang des Befehls ein Doorbell Event an den VMM gesendet hat (z.B. um dem VMM anzuzeigen, dass er die Verarbeitung von Befehlen im Command Ring der VM unterstützen soll). Als weiteres Beispiel kann die Firmware des Host-Controllers prüfen, ob eine von einem Befehl angegebene Speichergröße gültig ist (z.B. kann ein TRB 16 Byte betragen und kann eine größere oder kleinere Größe einen ungültigen Befehl anzeigen). Wenn der Befehl nicht validiert ist, kann die Firmware des Host-Controllers das Lesen der Speicherplätze unterlassen und/oder den VMM(s) keinen Zugriff auf die aus den Speicherplätzen gelesenen Daten gewähren.
In weiteren Aspekten der Erfindung kann die Firmware des Host-Controllers zusätzlich zur Validierung des Befehls durch die Firmware des Host-Controllers oder anstelle dieser Validierung die aus den Speicherplätzen gelesenen Daten validieren. Beispielsweise kann die Firmware des Host-Controllers die Daten lesen und bestätigen, dass die Daten ein korrektes Format haben und/oder korrekte Informationen oder Parameter enthalten. Dies kann die Überprüfung beinhalten, dass ein Anfragetyp-Feld einen gültigen Wert hat, dass ein oder mehrere reservierte Felder einen erwarteten Wert haben, dass eine Slot-Kennung (ID) innerhalb eines vorbestimmten Bereichs liegt und/oder dass die Daten in einem vordefinierten Format vorliegen. Im Beispiel einer xHCI-Schnittstelle kann dies die Überprüfung beinhalten, dass ein TRB-Typfeld innerhalb eines gültigen Bereichs liegt, eines oder mehrere reservierte Felder gleich Null sind, die Slot-ID innerhalb eines vorgegebenen Bereichs liegt und/oder die Daten in einem TRB-Format vorliegen. Falls die gelesenen Daten nicht validiert werden, kann die Firmware des Host-Controllers dem/den VMM den Zugriff auf die aus den Speicherplätzen gelesenen Daten verweigern.
In jedem Beispiel kann die Firmware dann, wenn der Befehl und/oder die Daten nicht validiert (z.B. als ungültig bestimmt) wird/werden, ein Befehlsabschlussereignis (z.B. CCode=0) an die VMM(s) liefern, das ein Fehlschlagen des Befehls anzeigt. Wenn der Befehl und/oder die Daten validiert sind, kann die Firmware des Host-Controllers den VMM(s) Zugriff auf die Daten gewähren, z.B. durch Kopieren der Daten in VMM-Speicher. Ferner kann die Firmware des Host-Controllers ein Befehlsabschlussereignis (z.B. CCode=1) an die VMM(s) liefern, das einen Erfolg des Befehls anzeigt. Dies kann dem VMM anzeigen, dass er die Daten aus dem VMM-Speicher lesen darf.
Nun auf 1 Bezug nehmend, ist 1 ein Diagramm eines Beispiels einer Betriebsumgebung 100 zur Validierung des Zugriffs von Virtualisierungssoftware auf Daten in Speicher, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Es versteht sich, dass diese und andere Anordnungen, die hierin beschrieben sind, nur als Beispiele dargestellt sind. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und manche Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionelle Entitäten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hierin beschriebene Funktionen, die von Entitäten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in Speicher gespeicherte Anweisungen ausführt.
Die Betriebsumgebung 100 kann unter anderem ein oder mehrere Hostsysteme 102 und ein oder mehrere externe Vorrichtungen bzw. Geräte 130 beinhalten. Die Betriebsumgebung 100 kann z.B. unter Verwendung eines oder mehrerer Computervorrichtungen 600 aus 6 implementiert sein. Das Hostsystem 102 kann einen VMM 104, eine Firmware/Hardware des Host-Controllers 106 (auch als „Host-Controller 106“ oder „Firmware des Host-Controllers 106“ bezeichnet), eine VM 108, eine VM 110, eine VM 114, eine VM 116 und einen Speicher 118 beinhalten. Der VMM 104 kann einen VMM-Speicher 134, einen Schnittstellenmanager 136, einen Kommunikationsprozessor 138 und einen Speicherabbilder 140 beinhalten. Die Firmware des Host-Controllers 106 kann einen Validator 142, einen Kommunikationsprozessor 144 und einen Schnittstellenmanager 146 beinhalten. Der Speicher 118 kann einen VM-Speicher 120, einen VM-Speicher 122, einen VM-Speicher 124 und einen VM-Speicher 126 enthalten.
Das/die Hostsystem(e) 102 kann/können dazu konfiguriert sein, eine oder mehrere virtualisierte Umgebungen zu hosten. Die virtualisierten Umgebungen können durch Virtualisierungssoftware verwaltet werden, zu der beispielsweise der eine oder die mehreren VMMs 104 gehören kann/können. Der/die VMM(s) 104 kann/können einen Überwacher bzw. Hypervisor des Hostsystems 102 beinhalten. Der Hypervisor kann eine beliebige Anzahl von VMs, wie beispielsweise die VMs 108, 110, 114 oder 116 (z.B. Gast-VMs), und/oder Virtualisierungsdienste (z.B. den VMM 104) der virtuellen Umgebung(en) erstellen und ausführen.
Der VMM 104 kann neben anderen möglichen Funktionalitäten dazu konfiguriert sein, (z.B. unter Verwendung eines xHCI-kompatiblen Servers) eine Verbindung zwischen einer beliebigen der VMs, wie beispielsweise der VM 108, und einer anderen Entität über den Host-Controller 106 unter Verwendung einer VF zu ermöglichen. Beispiele für die andere Entität beinhalten eine Entität innerhalb des Host-Systems 102 (z.B. die VM 116) oder eine Entität außerhalb des Host-Systems (z.B. das externe Gerät 130). Der Schnittstellenmanager 136 des VMM 104 kann dazu konfiguriert sein, die Kommunikation zu dem und von dem VMM 104 zu verwalten. Der Kommunikationsprozessor 138 des VMM 104 kann dazu konfiguriert sein, Kommunikationen zu erzeugen, wie beispielsweise Lesebefehle zum Lesen von VM-Speicher, und/oder empfangene Kommunikationen zu verarbeiten, z.B. Doorbell Events oder Anforderungsbefehle in dem VMM-Speicher 134 von VMs. Der Speicherabbilder 140 des VMM 104 kann dazu konfiguriert sein, Daten, die einer VF oder VM entsprechen, einer entsprechenden Speicheradresse in dem Speicher 118 (z.B. dem VM-Speicher 120 für die VM 108) für einen Lesebefehl zum Lesen von Daten aus dem VM-Speicher zuzuordnen.
Der Host-Controller 106 kann neben anderen möglichen Funktionalitäten dazu konfiguriert sein, eine Schnittstelle für die Verbindungen zwischen VMs und anderen Entitäten bereitzustellen und ebenso die Lesebefehle von dem VMM 104 und/oder aus dem VM-Speicher gelesene Daten zu validieren. Zum Beispiel kann der Schnittstellenmanager 146 des Host-Controllers 106 dazu konfiguriert sein, die Kommunikationen zu dem und von dem Host-Controller 106 zu verwalten. Der Kommunikationsprozessor 144 des Host-Controllers 106 kann dazu konfiguriert sein, empfangene Kommunikationen, wie z.B. Doorbell Events von VMs, die Lesebefehle von der VMM 104 und/oder aus dem VM-Speicher basierend auf den Lesebefehlen, wie z.B. Anforderungsbefehlen von VMs, gelesene Daten zu verarbeiten. Der Kommunikationsprozessor 144 des Host-Controllers 106 kann darüber hinaus dazu konfiguriert sein, Kommunikationen, wie z.B. Doorbell Events für die VMM 104, zu erzeugen. Zumindest ein Teil der von dem Kommunikationsprozessor 144 durchgeführten Verarbeitung kann den Validator 142 des Host-Controllers 106 dazu verwenden, einen Lesebefehl und/oder die aus dem VM-Speicher einer VM gelesenen Daten zu validieren, wie hierin beschrieben. Nach der Validierung kann der Schnittstellenmanager 146 des Host-Controllers 106 die Daten dem VMM-Speicher 134 zur Verwendung beim Aufbau und/oder bei der Änderung einer Verbindung zwischen der VM und einer anderen Entität bereitstellen. Der Schnittstellenmanager 146 kann dann direkt mit der VM und der anderen Entität kommunizieren, um die Verbindung zu hosten, ohne dass die Verwendung des VMM 104 (z.B. für datenübertragungsbezogene Arbeiten) erforderlich ist.
Das Host-System 102 kann auf einem oder mehreren integrierten Schaltkreisen (ICs) implementiert sein, die ein oder mehrere System-on-Chip (SoCs) und/oder Grafikverarbeitungseinheiten (GPUs) beinhalten können, aber nicht darauf beschränkt sind. Das Host-System 102 kann generell in jeder beliebigen Anwendung eingesetzt werden, in welcher eine VM mit einer anderen Entität über eine Host-Controller-Schnittstelle kommuniziert. In einigen Beispielen kann das Host-System 102 zumindest einen Teil eines eingebetteten Systems, wie z.B. eine elektronische Steuereinheit (ECU), bilden. Das Host-System 102 kann z.B. in nicht-autonomen Fahrzeugen, teilautonomen Fahrzeugen (z.B. in einem oder mehreren fortschrittlichen Fahrerassistenzsystemen (ADAS)), Robotern, Lagerfahrzeugen, Geländefahrzeugen, Luftschiffen, Booten und/oder anderen Fahrzeugtypen eingebaut sein. Das Host-System 102 kann die VM 108, 110, 114 oder 116 z. B. verwenden, um Steuerungen für Beschleuniger, Bremsen und/oder Funktionen einer oder mehrerer Vorrichtungen zu bestimmen und/oder zu übermitteln (z.B. unter Verwendung des Host-Controllers 106). Dies kann für ADAS, Robotik (z.B. Wegplanung für einen Roboter), Luftfahrtsysteme (z.B. Wegplanung für eine Drohne oder ein anderes Luftfahrzeug), Bootssysteme (z.B. Wegplanung für ein Boot oder ein anderes Wasserfahrzeug) und/oder andere Technologien verwendet werden.
Jede der VMs 108, 110, 114 und 116 des Host-Systems 102 kann eine virtuelle Computervorrichtung sein. Jede der VMs 108, 110, 114 und 116 kann über separate Fähigkeiten und Betriebsadressräume in dem Speicher 118 verfügen. Zum Beispiel können die VMs 108, 110, 114 und 116 jeweils Adressräume haben, die dem VM-Speicher 120, dem VM-Speicher 122, dem VM-Speicher 124 bzw. dem VM-Speicher 126 entsprechen. Der Speicher 118 kann sich auf ein oder mehrere physische Speichervorrichtungen beziehen, und der Hypervisor und/oder der VMM 104 können dafür verantwortlich sein, die Fähigkeit der VMs 108, 110, 114 und 116 zu unterstützen, das/die physische(n) Vorrichtung(en) gemeinsam zu nutzen und dabei die unterschiedlichen Adressräume zu erzwingen. In einigen Beispielen befindet sich jede VM auf einer anderen Partition, die von dem Hypervisor und/oder dem VMM 104 unterstützt wird.
Eine oder mehrere der VMs 108, 110, 114 oder 116 können Kommunikationen mit Peripheriegeräten (z.B. dem externen Gerät 130) und Komponenten über den Host-Controller 106 empfangen und bereitstellen. Beispiele für das externe Gerät 130 beinhalten jedes beliebige Gerät, das in der Lage ist, mit einer VM über eine Host-Controller-Schnittstelle zu kommunizieren, wie z.B. ein Steuergerät bzw. eine ECU, ein USB-Laufwerk, eine Kamera, ein Smartphone, eine VM, ein Laptop, ein Personal Computer, eine Netzwerkvorrichtung, ein Peripheriegerät, eine Clientvorrichtung usw. Jede VM kann ein OSI umfassen, wie z.B. ein Gast-OS bzw. Gastbetriebssystem, zu dessen Beispielen Implementierungen von Linux, Android, GENIVI, QNX, usw. gehören. Als ein spezifisches Beispiel für Implementierungen autonomen Fahrens kann eines der Gast-Betriebssysteme ein fahrzeuginternes Unterhaltungssystem bzw. In-Vehicle Infotainment (IVI)-System, ein anderes einen Fahrzeug-Cluster, ein anderes ein kopfgestütztes Anzeigesystem bzw. Heads-Up-Display (HUD)-System und wieder ein anderes ein ADAS und/oder ein autonomes Fahrsystem steuern. Eine beliebige Anzahl von Kommunikationen, die zur Implementierung dieser Funktionalität verwendet werden, können über die von dem Host-Controller 106 bereitgestellte Schnittstelle bereitgestellt werden.
In verschiedenen Beispielen kann jede der VMs 108, 110, 114 und 116 einen Command Ring aufweisen, welchem die VM eine beliebige Anzahl von Befehlen bereitstellen kann. Jede VM kann die Befehle in dem Speicher der VM (z.B. im Adressraum) in dem Speicher 118 bereitstellen. Beispielsweise kann die VM 108 dem VM-Speicher 120, der der VM 108 zugeordnet ist, einen Befehl bereitstellen. Ein Beispiel eines solchen Befehls beinhaltet einen Anforderungsbefehl, den eine VM verwenden kann, um Informationen bezüglich einer Verbindung und/oder Gerätefähigkeiten (z.B. des externen Geräts 130) anzufordern, um eine Verbindung zu einem anderen Gerät, wie beispielsweise dem externen Gerät 130 oder einer anderen VM oder einem logischen Gerät oder einer Komponente, herzustellen und/oder zu ändern. Der VMM 104 und/oder der Hypervisor können den Anforderungsbefehl verwenden, um die Verbindung zu modifizieren und/oder herzustellen. Wenn es sich bei dem externen Gerät 130 beispielsweise um eine Digitalkamera handelt, kann ein Anforderungsbefehl angeben, welche Formate oder Übertragungen die Digitalkamera unterstützt.
Der Anforderungsbefehl kann abhängig von der von dem Host-Controller 106 implementierten Controller-Schnittstelle und/oder anderen Verbindungskriterien in unterschiedlichen Formaten vorliegen und/oder unterschiedliche Arten von Informationen beinhalten. Wenn die Controller-Schnittstelle auf xHCI basiert, kann beispielsweise der Befehl TRB-Daten beinhalten. Die TRB-Daten können in Form einer in dem Speicher aufgebauten Datenstruktur vorliegen und Informationen wie beispielsweise ein TRB-Typfeld, ein oder mehrere reservierte Felder und eine Slot-ID beinhalten. Jeder VF (und VM) kann unter Verwendung einer Slot-ID ein Slot zugewiesen sein. Der Slot kann eine Slot-Kontextadresse haben, die eine Slot-Kontext-Datenstruktur beinhaltet, die Informationen enthält, die sich auf ein Gerät bzw. eine Vorrichtung als Ganzes beziehen oder alle Endpunkte eines Geräts bzw. einer Vorrichtung betreffen. Der VMM 104 kann diese Slot-Kontextadresse lesen und PFs in einem Slot-Kontext programmieren.
Um die Sicherheit zu erhöhen, kann der VMM 104 und/oder der Hypervisor nicht die Fähigkeit haben, den Speicher der VM für die Command Ring-Verarbeitung direkt zu lesen. Falls beispielsweise die Virtualisierungssoftware kompromittiert wird, könnte der VMM 104 in der Lage sein, aus einer beliebigen Stelle in dem Speicher 118 und/oder innerhalb des Speichers einer bestimmten VM zu lesen. Um einen Anforderungsbefehl von einer VM zu lesen, kann der Schnittstellenmanager 136 des VMM 104 stattdessen einen Lesebefehl an den Host-Controller 106 geben, und kann der Schnittstellenmanager 146 des Host-Controllers 106 den Lesebefehl empfangen und im Ansprechen darauf einen oder mehrere Controller-Direktspeicherzugriffe (DMAs) verwenden, um die Daten aus dem VM-Speicher zu lesen. Der Schnittstellenmanager 146 des Host-Controllers 106 kann ferner dem VMM 104 Zugriff auf die Daten gewähren, wie beispielsweise durch Bereitstellen (z.B. Schreiben) der Daten in den VMM-Speicher 134, der von dem Schnittstellenmanager 136 des VMM 104 gelesen werden kann. Der VMM 104 kann dann den Kommunikationsprozessor 138 verwenden, um den Befehl zu verarbeiten und die Verbindung zu erleichtern. Der VMM-Speicher 134 ist als innerhalb des VMM 104 dargestellt, kann sich aber auch außerhalb des VMM 104 befinden. Ferner kann der VMM-Speicher 134 in dem Speicher 118 und/oder in verschiedenen anderen Komponenten des Host-Systems 102 enthalten sein. Der VMM-Speicher 134 kann sich allgemein auf Speicherplätze beziehen, die für den Schnittstellenmanager 136 des VMM 104 zugänglich sind.
Der VMM 104 kann dazu konfiguriert sein, zumindest einige Virtualisierungsdienste für jede der VMs 108, 110, 114 und 116 bereitzustellen. Dies kann beinhalten, dass der VMM 104 die Fähigkeiten und den Betriebsregisterraum jeder der VMs 108, 110, 114 und 116 erfasst. In einigen Ausführungsformen ist der VMM 104 dazu konfiguriert, eine Virtualisierung der VMs 108, 110, 114 und 116 auf Root-Port-Ebene durchzuführen, wobei alle Geräte mit einem Root-Port verbunden sein können und einem darin arbeitenden Gastbetriebssystem zugeordnet sein können. Der VMM 104 kann auch die physische Funktion und den Command Ring jeder der VMs 108, 110, 114 und 116 verwalten. In einigen Ausführungsformen kann der VMM 104 über den Schnittstellenmanager 136 benachrichtigt werden, wann immer eine VF versucht, auf Fähigkeiten und Betriebsregisterraum des Host-Controllers 106 zuzugreifen. PF-Command- und -Event-Ringe des VMM 104 können dazu konfiguriert sein, VF-Befehle unter Verwendung des Kommunikationsprozessors 138 zu verarbeiten und Ereignis-TRBs von dem Host-Controller 106 unter Verwendung des Schnittstellenmanagers 136 zu empfangen. Der Schnittstellenmanager 136 des VMM 104 kann darüber hinaus Anschluss- bzw. Pad-Interrupts für alle mit dem Host-Controller 106 verbundenen Ports empfangen, welche der Schnittstellenmanager 136 dann in Form einer Inter-VM-Kommunikationsnachricht (IVC) an eine entsprechende VM weiterleiten kann.
Die Firmware des Host-Controllers 106 kann eine vertrauenswürdige Entität des Host-Systems 102 sein, die signiert und authentifiziert ist, wenn sie von dem Host-System 102 über die Vertrauenskette des Systems geladen wird. Die Firmware des Host-Controllers 106 kann eine Vielzahl von Host-Controller-Schnittstellen unterstützen, wie beispielsweise diejenigen, die für Universal Serial Bus (USB), Fire Wire, Bluetooth, Ethernet, Peripheral Component Interconnect (PCI), Near-Field Communication (NFC), Vehicle-to-Everything (V2X), Car2Car, Cellular, Wireless Fidelity (WiFi) oder andere Arten der Kommunikation verwendet werden.
Die Firmware des Host-Controllers 106 kann bestimmen, worauf in dem Speicher 118 zugegriffen werden soll, wie dies sicher geschehen soll und wie die Ergebnisse anderen Komponenten des Host-Systems 102 zur Verfügung gestellt werden. Zu diesem Zweck kann der Host-Controller 106 den Validator 142 dazu verwenden, die Lesebefehle von dem VMM 104 und/oder die aus dem Speicher 118 gelesenen Daten als Reaktion auf die Lesebefehle zu validieren, um den Zugriff auf die Daten zu regeln. Um einen Lesebefehl von der VM zu validieren, kann der Validator 142 bestätigen, dass der Lesebefehl mit einem Doorbell Event für einen Command Ring einer entsprechenden VM übereinstimmt. Wenn die VM 108 zum Beispiel einen Anforderungsbefehl in den VM-Speicher 120 schreibt, kann sie ein Doorbell Event bereitstellen, das von dem Schnittstellenmanager 146 der Firmware des Host-Controllers 106 empfangen wird. Falls ein solches Doorbell Event nicht von der VM 108 empfangen wurde, aber der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 einen Lesebefehl empfangen hat, der fordert, dass die Firmware des Host-Controllers 106 aus dem VM-Speicher 120 liest, kann der Validator 142 bestimmen, dass der Lesebefehl ungültig ist.
Als ein weiteres Beispiel kann der Validator 142 bestätigen, dass der Schnittstellenmanager 146 des Host-Controllers 106 vor dem Empfangen des Lesebefehls ein Doorbell Event an den VMM 104 gesendet hat. Zum Beispiel kann in einigen Ausführungsformen der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 im Ansprechen auf den Empfang des Doorbell Events von der VM 108 ein entsprechendes Doorbell Event an den VMM 104 senden. Das Doorbell Event an den VMM 104 kann dem VMM 104 anzeigen, dass er den Speicherabbilder 140 verwenden soll, um eine Speicheradresse für die VM 108 zu bestimmen und die Speicheradresse oder einen anderen Indikator für einen oder mehrere Speicherplätze in dem Lesebefehl an den Host-Controller 106 zu liefern. Falls ein solches Doorbell Event nicht von dem Schnittstellenmanager 146 des Host-Controllers 106 an den VMM 104 geliefert wurde, aber ein Lesebefehl empfangen wird, der die Firmware des Host-Controllers 106 auffordert, aus dem VM-Speicher 120 zu lesen, kann der Validator 142 bestimmen, dass der Lesebefehl ungültig ist.
In jedem Beispiel kann der Validator 142 des Host-Controllers 106 Informationen in dem Lesebefehl verwenden, um zu bestimmen, ob der Lesebefehl gültig ist. Zum Beispiel kann der Lesebefehl eines oder mehr einer Slot-ID, einer VF-ID, einer Speicheradresse, aus der gelesen werden soll, oder einer Speichergröße, die gelesen werden soll, umfassen. In einigen Beispielen kann der Validator 142 des Host-Controllers 106 bestimmen, dass ein Lesebefehl ungültig ist, falls die VF-ID nicht mit der ID einer VF übereinstimmt, die der Firmware des Host-Controllers 106 von der VM 108 in dem Doorbell Event bereitgestellt wurde. Darüber hinaus kann in einigen Beispielen der Validator 142 des Host-Controllers 106 bestimmen, dass ein Lesebefehl ungültig ist, falls die Slot-ID nicht mit der ID eines Slots übereinstimmt, der der Firmware des Host-Controllers 106 von der VM 108 in dem Doorbell Event bereitgestellt wurde.
Als ein weiteres Beispiel kann der Validator 142 des Host-Controllers 106 den Lesebefehl auf der Grundlage der durch den Lesebefehl angegebenen Speichergröße validieren. Dies kann eine Bestimmung beinhalten, dass die Speichergröße innerhalb eines vorbestimmten Bereichs liegt und/oder eine vorbestimmte Größe hat (die auf der Grundlage anderer Faktoren variieren kann). Beispielsweise kann ein TRB 16 Byte groß sein und kann eine größere oder kleinere Größe einen ungültigen Befehl anzeigen. Falls also der Validator 142 bestimmt, dass die Speichergröße nicht gleich 16 Byte ist, kann der Validator 142 bestimmen, dass der Lesebefehl ungültig ist. Falls der Lesebefehl von dem Validator 142 nicht validiert wird, kann die Firmware des Host-Controllers 106 davon absehen, den Schnittstellenmanager 146 zu verwenden, um die von dem Lesebefehl angegebenen Speicherplätze zu lesen und/oder dem VMM 104 den Zugriff auf die aus den Speicherplätzen gelesenen Daten zu ermöglichen.
Zusätzlich zu oder anstelle der Validierung des Lesebefehls durch den Validator 142 des Host-Controllers 106 kann der Validator 142 die Daten validieren, die aus den durch einen Lesebefehl angegebenen Speicherplätzen gelesen wurden. Zum Beispiel kann der Validator 142 die Daten lesen und bestätigen, dass die Daten ein korrektes Format haben und/oder korrekte Informationen oder Parameter enthalten. Dies kann beinhalten, dass der Validator 142 prüft, ob ein Anforderungs- bzw. Anfragetyp-Feld einen gültigen Wert hat, ein oder mehrere reservierte Felder einen erwarteten Wert haben, eine Slot-ID innerhalb eines vorbestimmten Bereichs liegt und/oder die Daten in einem vordefinierten Format vorliegen. Der erwartete Wert und/oder der vorbestimmte Bereich können statische Werte haben oder dynamisch generiert werden. Des Weiteren kann einer der beiden Werte vorbestimmt oder von der Firmware des Host-Controllers 106 definiert sein, wie z.B. in die Firmware des Host-Controllers 106 kodiert sein. Beispielsweise kann jeder der Werte hartkodiert bzw. fest kodiert sein oder durch Code zur Laufzeit berechnet und/oder durch die Firmware des Host-Controllers 106 vorbestimmt werden. Im Beispiel einer xHCI-Schnittstelle kann dies eine Überprüfung beinhalten, dass ein TRB-Typ-Feld innerhalb eines gültigen Bereichs liegt, ein oder mehrere reservierte Felder gleich Null sind, die Slot-ID innerhalb eines vorgegebenen Bereichs liegt und/oder die Daten in einem TRB-Format vorliegen. Falls der Validator 142 die Daten nicht validiert (z.B. bestimmt, dass die Daten ungültig sind), kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 dem VMM 104 den Zugriff auf die aus den Speicherplätzen gelesenen Daten verweigern.
Nunmehr auf 2 Bezug nehmend, zeigt 2 ein Ablaufdiagramm eines Beispiels eines Prozesses 200 zur Validierung des Zugriffs von Virtualisierungssoftware auf Daten im Speicher, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Der beispielhafte Prozess 200 wird anhand der VM 108 und des VM-Speichers 120 von 1 veranschaulicht. Der Prozess 200 kann jedoch in ähnlicher Weise für die VMs und den VM-Speicher wie beispielsweise die VMs 110, 114 oder VM 116 von 1 und die VM-Speicher 122, 124 oder 126 ausgebildet sein. Die spezifische Anordnung und Zusammensetzung der Komponenten von 1 soll durch 2 nicht beschränkt werden und kann in einigen Ausführungsformen variieren. Obwohl der Prozess 200 mit Blöcken und Pfeilen dargestellt ist, ist dies nicht dazu gedacht, alle Ausführungsformen des Prozesses 200 auf eine bestimmte Reihenfolge oder auf bestimmte Operationen zu beschränken.
Bei 202 des Prozesses 200 kann der Schnittstellenmanager 136 des VMM 104 eine Benachrichtigung über ein verbindungsbezogenes Ereignis an die VM 108 senden. Die Benachrichtigung kann der VM 108 beispielsweise anzeigen, dass ein logisches oder physisches Gerät bzw. eine solche Entität (z.B. das externe Gerät 130) eine Verbindung mit einem Port (z.B. einem Root-Port) hergestellt hat und/oder das Gerät/die Entität eine neue oder geänderte Verbindung zu der VM 108 anfordert. Zum Beispiel kann der VMM 104 vor dem Prozess 200 optional das verbindungsbezogene Ereignis über eine VF (z.B. basierend auf einer Anfrage von der Entität und/oder dem externen Gerät) erkennen. In einigen Ausführungsformen kann dies beinhalten, dass der Schnittstellenmanager 136 des VMM 104 einen Anschlussunterbrechung bzw. einen Pad-Interrupt für den der VM 108 zugeordneten Port empfängt. Der Schnittstellenmanager 136 des VMM 104 kann dann bei 202 die entsprechende Informationen (z.B. Interrupt-Informationen) umfassende Benachrichtigung in Form einer Inter-VM-Kommunikations (IVC)-Nachricht an die VM 108 weiterleiten.
Basierend auf dem Empfang der Benachrichtigung bei 202 kann die VM 108 bei 204A einen Anforderungsbefehl in den VM-Speicher 120 schreiben. Zum Beispiel kann die VM 108 den Anforderungsbefehl in den Command Ring der VM 108 schreiben. Der Anforderungsbefehl kann auf der Benachrichtigung basieren und kann z.B. eine Anforderung von Verbindungs- und/oder Geräteeigenschaften (z.B. für das verbundene Gerät) enthalten. Während ein Anforderungsbefehl beschrieben wird, kann der Anforderungsbefehl einer beliebigen Anzahl von Befehlen (z.B. mehreren Anforderungsbefehlen) entsprechen.
Ebenfalls basierend auf dem Empfang der Benachrichtigung bei 202 kann die VM 108 bei 204B die Firmware des Host-Controllers 106 über den bei 204A gespeicherten Befehl benachrichtigen. Beispielsweise kann die VM 108 nach, während oder vor 204A ein Doorbell Event an die Firmware des Host-Controllers 106 senden, um die Türklingel der Firmware des Host-Controllers 106 zu läuten. Der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 kann die Benachrichtigung empfangen und bei 206 eine Anforderung an den VMM 104 senden, basierend auf dem Empfang der Benachrichtigung bei 204B. In einigen Beispielen beinhaltet dies ein Weiterleiten des Doorbell Events an den VMM 104. In einigen Beispielen zeichnet der Kommunikationsprozessor 144 Informationen bezüglich der Benachrichtigung von der VM 108 auf, die der Validator 142 verwenden kann, um von dem VMM 104 empfangene Leseanforderungen zu validieren. Dies kann z.B. eine Anzahl von Benachrichtigungen, die von der VM 108 und/oder einer beliebigen VM empfangen wurden, eine Anzahl von Anforderungen, die an den VMM 104 auf der Grundlage von Benachrichtigungen, die von der VM 108 und/oder einer beliebigen VM empfangen wurden, gesendet wurden, und/oder eine VM-ID (z.B. VF-ID) der VM 108 beinhalten.
Die Anforderung (z.B. ein weitergeleitetes Doorbell Event) kann von dem Schnittstellenmanager 136 der VMM 104 empfangen werden und der VMM 104 anzeigen, dass sie bei der Verarbeitung des/der Anforderungsbefehls/-befehle im VM-Speicher 120 helfen soll (z.B. helfen soll, einen oder mehrere Befehle in dem Command Ring der VM 108 zu verarbeiten). Der Kommunikationsprozessor 144 des VMM 104 kann die Anforderung von 206 verarbeiten und den Speicherabbilder 140 verwenden, um die Anforderung auf einen oder mehrere Speicherplätze abzubilden. Der Kommunikationsprozessor 144 kann den einen oder die mehreren Speicherplätze verwenden, um einen Lesebefehl zu erzeugen, und der Schnittstellenmanager 136 der VMM 104 kann den Lesebefehl dem Host-Controller 106 bei 208 bereitstellen. Wie hierin erörtert wurde, kann der Lesebefehl den einen Speicherplatz oder die mehreren Speicherplätze angeben, den/die der Host-Controller 106 lesen soll, wie beispielsweise unter Verwendung einer Speicheradresse in dem Speicher 118 und einer Speichergröße für den Lesevorgang. Der Lesebefehl kann auch eine Slot-ID oder VF-ID der VM 108 beinhalten.
Der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 kann den/die Lesebefehl(e) von dem VMM 104 empfangen und der Kommunikationsprozessor 144 kann Informationen in dem/den Lesebefehl(en) verwenden, um den/die Anforderungsbefehl(e) (z.B. Befehls-TRB-Daten), die von der VM 108 bei 204A in dem VM-Speicher 120 gespeichert wurden, bei 210A zu lesen. Der Kommunikationsprozessor 144 kann z.B. die Slot-ID oder VF-ID verwenden, um die eindeutige Stream-ID für die VM 108 zu ermitteln. Der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 kann die Stream-ID, die Speicheradresse und die Speichergröße verwenden, um aus dem VM-Speicher 120 zu lesen. In dem Host-System 102 können Stream-IDs in einem anderen Hardware-Register durch den Hypervisor separat programmiert und für Speicherzugriffssicherheit verwendet werden, wobei unterschiedliche Stream-IDs unterschiedlichen VFs/VMs zugewiesen sind.
Vor, während und/oder nach 210A kann der Kommunikationsprozessor 144 den Validator 142 verwenden, um einen oder mehrere der Lesebefehl von 208 und/oder die bei 210A gelesenen Daten zu validieren. Zum Beispiel kann in einigen Ausführungsformen dann, wenn der Validator 142 bestimmt, dass der Lesebefehl ungültig ist, 210A nicht durchgeführt werden. In anderen Beispielen kann der Validator 142 die Daten bei 210A auch dann noch lesen, wenn der Lesebefehl für ungültig befunden wird. Darüber hinaus kann der Validator 142 die Daten analysieren oder nicht, um festzustellen, ob die Daten gültig sind. In einigen Beispielen liest der Validator 142 die Daten immer ohne Validierung, wenn möglich, und führt dann die Validierung an den Daten durch.
Nachdem die Daten bei 210A gelesen wurden, kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 die Daten und/oder Informationen, die durch die Daten repräsentiert werden, dem VMM 104 zur Verfügung stellen. In dem gezeigten Beispiel kann der Schnittstellenmanager 146 dies tun, indem er die Informationen (z.B. die Befehls-TRB-Daten) in dem VMM-Speicher 134 bei 210B speichert. Darüber hinaus kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 bei 212 eine oder mehrere Benachrichtigung(en) an den VMM 104 übermitteln. Die Benachrichtigung(en) kann/können dem VMM 104 anzeigen, dass sich die Informationen aus 210B im VMM-Speicher 134 befinden, dass der/die Lesebefehl(e) aus 208 von dem Validator 142 für gültig befunden wurde(n), und/oder dass die bei 210A gelesenen Daten von dem Validator 142 für gültig befunden wurden. Die Benachrichtigung kann z.B. als ein Befehlsabschlussereignis bezeichnet werden. In einigen Ausführungsformen kann das Befehlsabschlussereignis einen CCode = 1 enthalten, der einen Erfolg bei der Validierung der Daten und/oder des Lesebefehls anzeigt. Wären die Daten und/oder der Lesebefehl von dem Validator 142 nicht für gültig befunden worden, kann das Befehlsabschlussereignis (z.B. CCode) anzeigen, dass eine oder mehrere der Daten und/oder des Lesebefehls als ungültig befunden wurden. Zum Beispiel kann das Befehlsabschlussereignis einen CCode = 0 enthalten, was einen Fehler bei der Validierung der Daten und/oder des Lesebefehls anzeigt. Darüber hinaus kann es sein, dass die Informationen bei 210B nicht in dem VMM-Speicher 134 gespeichert wurden, wenn ein Datum oder mehrere der Daten und/oder der Lesebefehl für ungültig befunden wurden.
Der Schnittstellenmanager 136 des VMM 104 kann die Benachrichtigung von 212 von der Firmware des Host-Controllers 106 empfangen und auf der Grundlage der Benachrichtigung die Informationen aus dem VMM-Speicher 134 lesen. Beispielsweise kann der Kommunikationsprozessor 144 bestimmen, dass der Lesebefehl von 208 erfolgreich war (z.B. durch Identifizierung von CCode = 1 in dem Befehlsabschlussereignis) und auf der Grundlage dieser Bestimmung die Informationen bei 214 lesen. Wäre der Lesebefehl fehlgeschlagen, könnte der VMM 104 nicht versuchen, die Informationen zu lesen, und könnte optional eine andere Aktion durchführen. Zum Beispiel kann der VMM 104 die VM 108 über den Fehler informieren. Wenn der VMM 104 die Informationen bezüglich des Anforderungsbefehls bei 214 erfolgreich von der VM 108 empfängt, kann der Kommunikationsprozessor 138 die Informationen verarbeiten und die Ergebnisse (z.B. die angeforderten Informationen) an die VM 108 senden (z.B. in einem Befehlsabschlussereignis TRB). Anschließend kann die Verbindung zum Gerät/zu der Entität hergestellt und/oder auf der Grundlage der Ergebnisse geändert werden.
Nunmehr auf 3-5 Bezug nehmend, umfasst jeder Block von hierin beschriebenen Verfahren 300, 400 und 500 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren 300, 400 und 500 können auch als computerverwendbare Anweisungen, die auf Computerspeichermedien gespeichert sind, verkörpert sein. Die Verfahren 300, 400 und 500 können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt sein, um einige nicht beschränkende Beispiele zu nennen. Darüber hinaus werden die Verfahren 300, 400 und 500 beispielhaft in Bezug auf das Host-System 102 von 1 beschrieben. Diese Verfahren 300, 400 und 500 können jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich der, aber nicht beschränkt auf die, hierin beschriebenen Systeme. Ferner können die Verfahren 300, 400 oder 500 dem Prozess 200 von 2 entsprechen oder nicht.
Nunmehr auf 3 Bezug nehmend, zeigt 3 ein Ablaufdiagramm eines Beispiels eines Verfahrens zur Validierung von Daten, die im Ansprechen auf einen Lesebefehl von Virtualisierungssoftware aus VM-Speicher gelesen wurden, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 300 umfasst bei Block B302 ein Empfangen eines Befehls, der eine Speicheradresse einer virtuellen Maschine angibt. Zum Beispiel kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 von 1 einen Befehl (z.B. einen Lesebefehl) von dem VMM 104 empfangen. Der Befehl kann eine Speicheradresse der VM 108 angeben.
Das Verfahren 300 umfasst bei Block 8304 ein Lesen von Daten aus der Speicheradresse. Zum Beispiel kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 basierend auf dem Empfang des Befehls Daten aus der Speicheradresse in dem VM-Speicher 120 lesen.
Das Verfahren 300 beinhaltet bei Block B306 ein Validieren der aus der Speicheradresse gelesenen Daten. Zum Beispiel kann der Validator 142 der Firmware des Host-Controllers 106 die aus der Speicheradresse gelesenen Daten validieren.
Das Verfahren 300 umfasst bei Block B308 ein Bereitstellen des Zugriffs auf die gelesenen Daten für einen VMM. Beispielsweise kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 basierend auf der Validierung (z.B. über den VMM-Speicher 134) dem VMM 104 einen Zugriff auf die aus der Speicheradresse gelesenen Daten gewähren.
Das Verfahren 300 umfasst bei Block B310 ein Senden eines Befehlsabschlussereignisses. Beispielsweise kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 ein Befehlsabschlussereignis an den VMM 104 senden, das anzeigt, dass die aus der Speicheradresse gelesenen Daten validiert sind.
Wären die Daten bei Block B306 nicht validiert worden, könnte zumindest Block B308 nicht ausgeführt werden. Darüber hinaus kann in einigen Ausführungsformen, wären die Daten bei Block B306 nicht validiert worden, das Befehlsabschlussereignis bei Block B310 anzeigen, dass die Daten nicht validiert (z.B. als ungültig befunden) wurden.
Bezugnehmend auf 4, zeigt 4 ein Ablaufdiagramm eines Beispiels eines Verfahrens 400 zur Validierung eines Befehls von Virtualisierungssoftware zum Lesen von VM-Speicher, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. In einigen Beispielen kann das Verfahren 400 in das Verfahren 300 integriert sein. In anderen Beispielen können das Verfahren 400 und das Verfahren 300 unabhängig voneinander sein.
Das Verfahren 400 beinhaltet bei Block B402 ein Empfangen eines Befehls, der eine Speicheradresse einer virtuellen Maschine angibt. Zum Beispiel kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 von 1 einen Befehl (z.B. einen Lesebefehl) von der VMM 104 empfangen. Der Befehl kann eine Speicheradresse der VM 108 angeben.
Das Verfahren 400 bei Block B404 kann ein Validieren des Befehls beinhalten. Beispielsweise kann der Kommunikationsprozessor 144 den Validator 142 dazu verwenden, den von dem VMM 104 empfangenen Befehl zu validieren.
Das Verfahren 400 bei Block B406 beinhaltet ein Lesen von Daten aus der Speicheradresse. Zum Beispiel kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 Daten aus der Speicheradresse in dem VM-Speicher 120 basierend auf dem Empfang des Befehls lesen. In einigen Ausführungsformen kann das Lesen der Daten aus der Speicheradresse darauf basieren, dass der Validator 142 den Befehl validiert. In anderen Beispielen können die Daten unabhängig davon gelesen werden, ob der Befehl als gültig bestimmt ist.
Das Verfahren 400 beinhaltet bei Block B408 ein Bereitstellen eines Zugriffs auf die gelesenen Daten für einen VMM. Beispielsweise kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 dem VMM 104 den Zugriff auf die aus der Speicheradresse gelesenen Daten basierend auf der Validierung (z.B. über den VMM-Speicher 134) gewähren.
Das Verfahren 400 beinhaltet bei Block B410 ein Senden eines Befehlsabschlussereignisses. Beispielsweise kann der Schnittstellenmanager 146 der Firmware des Host-Controllers 106 ein Befehlsabschlussereignis an den VMM 104 senden, das anzeigt, dass die aus der Speicheradresse gelesenen Daten validiert sind.
Wäre der Befehl bei Block B404 nicht validiert worden, könnte zumindest Block B408 nicht ausgeführt werden. Darüber hinaus kann in einigen Ausführungsformen, wären die Daten bei Block B404 nicht validiert worden, das Befehlsabschlussereignis in Block B410 anzeigen, dass der Befehl nicht validiert (z.B. als ungültig befunden) wurde und/oder Block B406 nicht ausgeführt wird. Ferner kann in einigen Fällen Block B406 vor Block B404 ausgeführt werden.
Bezugnehmend auf 5 zeigt 5 ein Ablaufdiagramm eines Beispiels eines Verfahrens 500 für Virtualisierungssoftware zum Lesen von Daten aus VM-Speicher unter Verwendung einer Firmware des Host-Controllers, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. In einigen Beispielen kann das Verfahren 500 in eines oder mehrere der Verfahren 300 oder 400 integriert sein. Zum Beispiel kann aus Sicht eines VMM das Verfahren 500 dem Verfahren 300 und/oder dem Verfahren 400 entsprechen. In anderen Beispielen können das Verfahren 500 und das Verfahren 300 oder das Verfahren 400 unabhängig voneinander sein.
Das Verfahren 500 beinhaltet bei Block B502 ein Senden eines Befehls, der eine Speicheradresse einer virtuellen Maschine angibt. Zum Beispiel kann der Schnittstellenmanager 136 des VMM 104 von 1 einen Befehl (z.B. einen Lesebefehl) an die Firmware des Host-Controllers 106 senden. Der Befehl kann eine Speicheradresse der VM 108 angeben. In einigen Ausführungsformen kann der Block B502 darauf basieren, dass der Schnittstellenmanager 136 des VMM 104 ein Doorbell Event von dem Host-Controller 106 empfängt, wie hierin beschrieben wurde.
Das Verfahren 500 umfasst bei Block B504 ein Empfangen eines Befehlsabschlussereignisses, das eine Validierung der aus der Speicheradresse gelesenen Daten, des Befehls oder beider anzeigt. Zum Beispiel kann der Schnittstellenmanager 136 des VMM 104 ein Befehlsabschlussereignis von der Firmware des Host-Controllers 106 empfangen. Das Befehlsabschlussereignis kann (z.B. über einen CCode, wie hier beschrieben wurde) eine Validierung des Befehls, der aus der Speicheradresse gelesenen Daten basierend auf dem Befehl oder beider durch die Firmware des Host-Controllers 106 anzeigen.
Das Verfahren 500 beinhaltet bei Block B506 ein Lesen der aus der Speicheradresse gelesenen Daten. Zum Beispiel kann der Schnittstellenmanager 136 des VMM 104 die aus der Speicheradresse gelesenen Daten lesen.
6 ist ein Blockdiagramm einer beispielhaften Computerumgebung, die in einigen Implementierungen der vorliegenden Anwendung für die Validierung des Zugriffs durch Virtualisierungssoftware auf Daten in Speicher geeignet ist. Die Computervorrichtung 600 kann einen Bus 602 beinhalten, der direkt oder indirekt die folgenden Geräte bzw. Vorrichtungen koppelt: Speicher 604, eine oder mehrere Zentralverarbeitungseinheiten (CPU) 606, eine oder mehrere Grafikverarbeitungseinheiten (GPU) 608, eine Kommunikationsschnittstelle 610, Eingabe-/Ausgabe (E/A)-Ports 612, Eingabe-/Ausgabe-Komponenten 614, eine Stromversorgung 616 und eine oder mehrere Darstellungskomponenten 618 (z.B. Anzeige(n)).
Obwohl die verschiedenen Blöcke von 6 als über den Bus 602 mit Leitungen verbunden dargestellt sind, ist dies nicht beschränkend und dient lediglich der Klarheit. Zum Beispiel kann in einigen Ausführungsformen eine Darstellungskomponente 618, wie beispielsweise eine Anzeigevorrichtung, als eine E/A-Komponente 614 betrachtet werden (z.B. falls die Anzeige ein Touchscreen ist). Als ein weiteres Beispiel können die CPU(s) 606 und/oder die GPU(s) 608 Speicher beinhalten (z.B. kann der Speicher 604 für eine Speichervorrichtung zusätzlich zu dem Speicher der GPU(s) 608, der CPU(s) 606 und/oder anderer Komponenten repräsentativ sein). Mit anderen Worten ist die Computervorrichtung von 6 lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle im Rahmen der Computervorrichtung von 6 denkbar sind.
Der Bus 602 kann einen oder mehrere Busse repräsentieren, wie z.B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Der Bus 602 kann einen oder mehrere Bustypen umfassen, z.B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus.
Der Speicher 604 kann ein beliebiges einer Vielzahl von computerlesbaren Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf die die Computervorrichtung 600 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie austauschbare und nichtentfernbare Medien umfassen. Beispielhaft und nicht beschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmanwendungen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 604 computerlesbare Anweisungen (die z.B. ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z.B. ein Betriebssystem) speichern. Computerspeichermedien können unter anderem und ohne Beschränkung darauf RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das die Computervorrichtung 600 zugreifen kann. Wie hierin verwendet umfasst das Computerspeichermedium nicht Signale per se.
Die Kommunikationsmedien können computerlesbare Anweisungen, Datenstrukturen, Programmanwendungen und/oder andere Datentypen in einem modulierten Datensignal, wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und beinhalten beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert sind, dass Informationen in dem Signal kodiert werden. Beispielhaft und nicht beschränkend können die Kommunikationsmedien verdrahtete Medien wie beispielsweise ein verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung und drahtlose Medien wie beispielsweise akustische, RF-, Infrarot- und andere drahtlose Medien beinhalten. Kombinationen beliebigen des Vorstehenden sind ebenfalls in den Rahmen computerlesbarer Medien aufzunehmen.
Die CPU(s) 606 kann/können dazu konfiguriert sein, die computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Computervorrichtung 600 zu steuern, um eines/einen oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 606 kann/können jeweils einen oder mehrere Kerne (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 606 kann/können jeden beliebigen Prozessortyp beinhalten und je nach Art der implementierten Computervorrichtung 600 unterschiedliche Prozessortypen (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server) beinhalten. Beispielsweise kann abhängig von der Art der implementierten Rechenvorrichtung 600 der Prozessor ein ARM-Prozessor, der mit RISC (Reduced Instruction Set Computing) implementiert ist, oder ein x86-Prozessor, der mit CISC (Complex Instruction Set Computing) implementiert ist, sein. Die Computervorrichtung 600 kann eine oder mehrere CPU(s) 606 zusätzlich zu einem oder mehreren Mikroprozessoren oder ergänzenden Koprozessoren, wie z.B. mathematischen Koprozessoren, beinhalten.
Die GPU(s) 608 kann/können von der Computervorrichtung 600 zum Rendern von Grafiken (z.B. 3D-Grafiken) verwendet werden. Die GPU(s) 608 kann/können Hunderte oder Tausende von Kernen beinhalten, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 608 kann/können im Ansprechen auf Rendering-Befehle (z.B. Rendering-Befehle von der/den CPU(s) 606, die über eine Host-Schnittstelle empfangen wurden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 608 kann/können Grafikspeicher, wie beispielsweise einen Anzeigespeicher, zum Speichern von Pixeldaten beinhalten. Der Anzeigespeicher kann als Teil des Speichers 604 enthalten sein. Die GPU(s) 608 kann/können zwei oder mehr GPU(s) beinhalten, die parallel (z.B. über eine Verbindung arbeiten). Wenn sie miteinander kombiniert werden, kann jede GPU 608 Pixeldaten für verschiedene Teile eines Ausgabebildes oder für verschiedene Ausgabebilder (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild) erzeugen. Jede GPU kann ihren eigenen Speicher haben oder sich Speicher mit anderen GPUs teilen.
In Beispielen, in denen die Computervorrichtung 600 keine GPU(s) 608 beinhaltet, kann/können die CPU(s) 606 zum Rendern von Grafiken und/oder zum Verarbeiten von Daten verwendet werden.
Die Kommunikationsschnittstelle 610 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Computervorrichtung 600 ermöglichen, mit anderen Computervorrichtungen über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich verdrahteter und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 610 kann Komponenten und Funktionen beinhalten, die Kommunikation über eine beliebige Anzahl verschiedener Netzwerke ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet), Weitverkehrsnetzwerke mit geringer Leistung (z.B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die E/A-Ports 612 können es der Computervorrichtung 600 ermöglichen, logisch mit anderen Vorrichtungen gekoppelt zu werden, einschließlich den E/A-Komponenten 614, den Darstellungskomponente(n) 618 und/oder anderen Komponenten, von denen einige in die Computervorrichtung 600 eingebaut (z.B. integriert) sein können. Illustrative E/A-Komponenten 614 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 614 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben verarbeitet, die von einem Benutzer erzeugt werden. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein entsprechendes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie nachstehend näher beschrieben) in Verbindung mit einer Anzeige der Computervorrichtung 600 implementieren. Die Computervorrichtung 600 kann Tiefenkameras, wie z.B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung beinhalten. Zusätzlich kann die Computervorrichtung 600 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) beinhalten, die die Erkennung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Computervorrichtung 600 dazu verwendet werden, eine immersive Augmented Reality oder Virtual Reality zu erzeugen.
Die Stromversorgung 616 kann eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination derselben beinhalten. Die Stromversorgung 616 kann die Computervorrichtung 600 mit Strom versorgen, um den Betrieb der Komponenten der Computervorrichtung 600 zu ermöglichen.
Die Darstellungskomponente(n) 618 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-Up-Display (HUD), andere Anzeigetypen oder eine Kombination derselben), Lautsprecher und/oder andere Darstellungskomponenten beinhalten. Die Darstellungskomponente(n) 618 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 608, der/den CPU(s) 606 usw.) empfangen und die Daten ausgeben (z.B. als Bild, Video, Ton usw.).
Die Erfindung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie beispielsweise Programmanwendungen beschrieben werden, die von einem Computer oder einer anderen Maschine, z.B. einem Personal Data Assistant oder einem anderen Handgerät, ausgeführt werden. Allgemeinen beziehen sich Programmanwendungen, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Erfindung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Computervorrichtungen usw. Die Erfindung kann auch in verteilten Computerumgebungen angewendet werden, in denen Aufgaben von ferngesteuerten Vorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
Wie hierin verwendet ist eine Wiedergabe von „und/oder“ in Bezug auf zwei oder mehr Elemente so zu interpretieren, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Beispielsweise kann „Element A, Element B und/oder Element C“ nur das Element A, nur das Element B, nur das Element C, das Element A und das Element B, das Element A und das Element C, das Element B und das Element C oder die Elemente A, B und C umfassen. Außerdem kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B beinhalten.
Der Gegenstand der Erfindung ist hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang der Erfindung nicht beschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden, um verschiedene Elemente der eingesetzten Verfahren zu bezeichnen, sind diese Begriffe nicht dahingehend zu interpretieren, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.

Claims

Verfahren, umfassend: Empfangen eines Befehls von einem Virtual Machine Manager (VMM), wobei der Befehl einer Anforderung durch ein Peripheriegerät entspricht und eine Speicheradresse in einem Speicher angibt, der in einer Computervorrichtung enthalten ist und einer virtuellen Maschine zugeordnet ist, die unter Verwendung der Computervorrichtung instanziiert wird, wobei die Computervorrichtung einen Host-Controller umfasst und die Computervorrichtung unter Verwendung des Host-Controllers kommunikativ mit dem Peripheriegerät gekoppelt ist; Lesen von Daten aus der Speicheradresse auf der Grundlage des Empfangs des Befehls; Validieren der aus der Speicheradresse gelesenen Daten durch eine Firmware des Host-Controllers, die dem Host-Controller entspricht; Bereitstellen eines Zugriffs auf die aus der Speicheradresse gelesenen Daten durch die Firmware des Host-Controllers für den VMM auf der Grundlage der Validierung; und Senden eines Befehlsabschlussereignisses an den VMM, das anzeigt, dass die aus der Speicheradresse gelesenen Daten validiert sind.
Verfahren nach Anspruch 1, wobei das Validieren der Daten ein Bestimmen umfasst, dass ein oder mehrere reservierte Felder, die durch die Daten repräsentiert werden, einen erwarteten Wert haben, der durch Code der Firmware des Host-Controllers definiert ist.
Verfahren nach Anspruch 1, wobei das Validieren der Daten ein Bestimmen einer durch die Daten repräsentierten Slot-ID umfasst, die innerhalb eines vorbestimmten Bereichs liegt, der durch den Code der Firmware des Host-Controllers definiert ist.
Verfahren nach Anspruch 1, wobei der Befehl die Speicheradresse und eine unter Verwendung der Speicheradresse zu lesende Datengröße umfasst.
Verfahren nach Anspruch 1, wobei das Validieren der Daten umfasst: Identifizieren eines durch die Daten repräsentierten Anforderungstyps; und Bestimmen, dass der Anforderungstyp in einer gültigen Gruppe von Anforderungstypen ist.
Verfahren nach Anspruch 1, wobei das Empfangen des Befehls vom dem VMM auf einem Erfassen einer Verbindung des Peripheriegeräts mit einem Host-Controller basiert und die Daten eine Anfrage von der VM nach Verbindungsfähigkeiten der Entität umfassen.
Verfahren, umfassend: Empfangen eines Befehls von einem Virtual Machine Manager (VMM), wobei der Befehl eine Speicheradresse in einem Speicher angibt, der in einer Computervorrichtung enthalten ist und einer virtuellen Maschine zugeordnet ist; Validieren des von dem VMM empfangenen Befehls durch eine Firmware des Host-Controllers; Lesen von Daten aus der Speicheradresse auf der Grundlage des Empfangs des Befehls; Bereitstellen eines Zugriffs auf die aus der Speicheradresse gelesenen Daten durch die Firmware des Host-Controllers für den VMM auf der Grundlage der Validierung; und Senden eines Befehlsabschlussereignisses an den VMM, das anzeigt, dass der Befehl validiert ist.
Verfahren nach Anspruch 7, ferner umfassend ein Validieren der aus der Speicheradresse gelesenen Daten durch die Firmware des Host-Controllers, wobei das Bereitstellen des Zugriffs auf die Daten für den VMM ferner auf dem Validieren der Daten basiert.
Verfahren nach Anspruch 7, wobei die Daten für einen Befehlsübertragungsanforderungsblock repräsentativ sind.
Verfahren nach Anspruch 7, wobei das Validieren des Befehls ein Bestimmen umfasst, dass der Befehl einem Doorbell Event zugeordnet ist, das eine Speicherleseanforderung von der VM anzeigt.
Verfahren nach Anspruch 7, wobei das Lesen der Speicheradresse von der Firmware des Host-Controllers unter Verwendung direkter Speicherzugriffe auf Speicher der virtuellen Maschine durchgeführt wird.
Verfahren nach Anspruch 7, wobei die Firmware des Host-Controllers von einem Host-Controller stammt, der in der Computervorrichtung enthalten ist, und der VMM die aus der Speicheradresse gelesenen Daten verwendet, um eine Verbindung zwischen der virtuellen Maschine und einem Peripheriegerät über den Host-Controller herzustellen oder zu ändern.
System, umfassend: einen Virtual Machine Manager (VMM), der unter Verwendung eines oder mehrerer Prozessoren einer Computervorrichtung ausgeführt wird zum: Senden eines Befehls an eine Firmware des Host-Controllers, wobei der Befehl eine Speicheradresse in einem Speicher angibt, der in der Computervorrichtung enthalten ist und einer virtuellen Maschine zugeordnet ist; Empfangen eines Befehlsabschlussereignisses, das eine Validierung eines Datums oder mehreren Daten, die aus der Speicheradresse gelesen wurden, oder des Befehls durch die Firmware des Host-Controllers angibt; und Verarbeiten der aus der Speicheradresse gelesenen Daten; und einen Host-Controller zum: Empfangen des Befehls von der VMM; Durchführen der Validierung eines oder mehrerer der aus der Speicheradresse gelesenen Daten oder des Befehls; und Senden des Befehlsabschlussereignisses an die VMM.
System nach Anspruch 13, wobei der VMM ferner ein Doorbell Event von der Host-Steuerung empfängt, wobei das Senden des Befehls auf dem Doorbell Event basiert.
System nach Anspruch 13, wobei der Befehl die Speicheradresse und eine von dem Host-Controller unter Verwendung der Speicheradresse zu lesende Datengröße umfasst.
System nach Anspruch 13, wobei die Validierung bestimmt, dass ein oder mehrere reservierte Felder, die durch die Daten repräsentiert werden, einen erwarteten Wert haben, der durch Code der Firmware des Host-Controllers definiert ist.
System nach Anspruch 13, wobei die Validierung bestimmt, dass eine durch die Daten repräsentierte Slot-ID innerhalb eines vorbestimmten Bereichs liegt, der durch Code der Firmware des Host-Controllers definiert ist.
System nach Anspruch 13, wobei der VMM ferner konfiguriert ist zum: Senden eines zusätzlichen Befehls an die Firmware des Host-Controllers, wobei der zusätzliche Befehl eine Speicheradresse der virtuellen Maschine angibt; und Empfangen eines zusätzlichen Befehlsabschlussereignisses, das einen Fehler anzeigt, durch die Firmware des Host-Controllers, um ein Datum oder mehrere Daten, die aus der Speicheradresse der virtuellen Maschine gelesen wurden, oder den zusätzlichen Befehl zu validieren.
System nach Anspruch 13, wobei das System ein autonomes Fahrzeug umfasst.
System nach Anspruch 13, wobei der VMM eine virtuelle Funktion auf die Speicheradresse abbildet und die Speicheradresse in den Befehl aufnimmt.