DE102019110023A1

DE102019110023A1 - System mit programmierbarer Multi-Kontext-Beschleuniger-Schaltung

Info

Publication number: DE102019110023A1
Application number: DE102019110023.2A
Authority: DE
Inventors: Utkarsh Y. Kakaiya; Pratik Marolia; Joshua David Fender; Sundar Nadathur; Nagabhushan Chitlur; Yuling Yang; David Alexander Munday
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-06-29
Filing date: 2019-04-16
Publication date: 2020-01-02
Also published as: CN110659245A; US20190042329A1

Abstract

Es wird ein System bereitgestellt, das einen Hostprozessor enthält, der an einen programmierbaren Beschleunigungscoprozessor gekoppelt ist. Der Coprozessor kann Logik zum Implementieren einer physischen Funktion und von mehreren assoziierten virtuellen Funktionen enthalten. Der Coprozessor kann einen statischen programmierbaren Ressourcenschnittstellenschaltkreis (PIC), der ausgelegt ist, Verwaltungsfunktionen durchzuführen, und eine oder mehrere Bereiche zur teilweisen Neukonfiguration enthalten, in die jeweils eine Beschleunigerfunktionseinheit (AFU) geladen werden kann. Eine AFU kann ferner in AFU-Kontexte (AFCs) partitioniert werden, die jeweils auf eine der virtuellen Funktionen abgebildet werden können. Der PIC ermöglicht eine Hardware-Entdeckung/Nummerierung und das Laden von Vorrichtungstreibern, sodass Sicherheitsisolation und Schnittstellenleistung beibehalten werden.

Description

Stand der Technik
Dies betrifft integrierte Schaltkreise und genauer programmierbare integrierte Schaltkreise in einer HardwareBeschleunigungsplattform.
Programmierbare integrierte Schaltkreise sind ein Typ von integriertem Schaltkreis, der von einem Benutzer programmiert werden kann, um eine gewünschte benutzerdefinierte Logikfunktion zu implementieren. In einem typischen Szenario verwendet ein Logikdesigner computerunterstützte Designwerkzeuge, um einen benutzerdefinierten Logikschaltkreis zu konstruieren. Wenn der Designprozess abgeschlossen ist, erzeugen die computerunterstützten Designwerkzeuge Konfigurationsdaten. Die Konfigurationsdaten werden in Arbeitsspeicherelemente auf einem programmierbaren integrierten Schaltkreis geladen, um die Vorrichtung zu konfigurieren, um die Funktionen des benutzerdefinierten Logikschaltkreises durchzuführen.
Programmierbare Vorrichtungen können zur gemeinsamen Verarbeitung in Massendaten- oder schnellen Datenanwendungen verwendet werden. Programmierbare Vorrichtungen können zum Beispiel in Anwendungsbeschleunigungsaufgaben in einem Rechenzentrum verwendet werden und können während einer Rechenzentrumoperation neu programmiert werden, um unterschiedliche Aufgaben durchzuführen. Durch das Auslagern von rechenintensiven Aufgaben von einem Hostprozessor auf hochparallele Beschleunigungsressourcen auf einer programmierbaren Vorrichtung (manchmal als Coprozessor oder Beschleunigungsprozessor bezeichnet) wird der Hostprozessor freigegeben, um andere kritische Verarbeitungsaufgaben durchzuführen. Die Verwendung von programmierbaren Vorrichtungen als Hardwarebeschleuniger kann deshalb bei der Lieferung von verbesserten Geschwindigkeiten, verbesserter Latenz, Leistungseffizienz und Flexibilität für durchgehendes Cloudrechnen, Vernetzen, Speichern, künstliche Intelligenz, autonomes Fahren, virtuelle Realität, erweiterte Realität, Gaming und andere datenzentrierte Anwendungen helfen.
Durch die wesentliche Erhöhung bei der Rechenleistung eines einzelnen Servers in Cloud-Rechenzentren in den letzten Jahren können bestimmte Arbeitslasten wesentlich unter der verfügbaren Verarbeitungsleistung des Servers liegen. Diese Nichtauslastung der verfügbaren Verarbeitungsfähigkeit hat die Einführung von Servervirtualisierung nach sich gezogen. Die Servervirtualisierung ermöglicht, dass mehrere virtuelle Maschinen (VMs) und Container als unabhängige virtuelle Server auf einem einzigen Hostprozessor/Server laufen. Auf einer Hardwarebeschleunigungsplattform ist ein programmierbarer integrierter Schaltkreis, wie eine feldprogrammierbare Gatearray-Vorrichtung (FPGA-Vorrichtung), die mit dem Hostprozessor verbunden ist, physisch in unabhängige Bereiche partitioniert, von denen jeder einer der virtuellen Maschinen oder einem der Container zugewiesen ist und als eine solche oder ein solcher dient. Ein derartiges physisches Partitionieren programmierbarer Ressourcen oder ein Zeitmultiplexen von derartig physisch partitionierten Ressourcen ermöglicht, dass die FPGA-Vorrichtung gleichzeitig von einer begrenzten Anzahl von virtuellen Maschinen verwendet wird.
In diesem Zusammenhang ergeben sich die hierin beschriebenen Ausführungsformen.
Figurenliste

1 ist ein Diagramm eines programmierbaren integrierten Schaltkreises nach einer Ausführungsform.
2 ist ein Diagramm eines beispielhaften Servers, der Hardwarebeschleunigungsressourcen nach einer Ausführungsform einsetzt.
3A ist ein Diagramm, das ein illustratives Abbildungsschema für vorgeschaltete Arbeitsspeicheranforderungen nach einer Ausführungsform zeigt.
3B ist ein Diagramm, das ein illustratives Abbildungsschema für nachgeschaltete Arbeitsspeicheranforderungen nach einer Ausführungsform zeigt.
4 ist ein Ablaufdiagramm von illustrativen Schritten zum Durchführen einer Rücksetzung auf Kontextebene für einen bestimmten Beschleunigerfunktionseinheitskontext (AFC) nach einer Ausführungsform.
5 ist ein Diagramm einer illustrativen Vorrichtungsfunktionsliste (DFL) aus der Perspektive einer physischen Funktion nach einer Ausführungsform.
6 ist ein Diagramm einer illustrativen Vorrichtungsfunktionsliste (DFL) aus der Perspektive einer virtuellen Funktion nach einer Ausführungsform.
7 ist ein Diagramm einer virtualisierten Vorrichtungsfunktionsliste (DFL) aus der Perspektive einer physischen Funktion nach einer Ausführungsform.
8 ist ein Diagramm einer virtualisierten Vorrichtungsfunktionsliste (DFL) aus der Perspektive einer virtuellen Funktion nach einer Ausführungsform.
9 ist ein Ablaufdiagramm von illustrativen Schritten zum Neukonfigurieren einer Beschleunigerfunktionseinheit (AFU) nach einer Ausführungsform.
10A ist ein Ablaufdiagramm von illustrativen Schritten zum Zuweisen einer virtuellen Funktion zu einem AFC nach einer Ausführungsform.
10B ist ein Ablaufdiagramm von illustrativen Schritten zum Entfernen einer virtuellen Funktion von einem AFC nach einer Ausführungsform.

Ausführliche Beschreibung
Die vorliegenden Ausführungsformen betreffen Verfahren und Einrichtungen zum Überbrücken statischer Vorrichtungsvirtualisierungstechnologien wie Einzel-Root-Eingabe/Ausgabe-Virtualisierung (SR-IOV) oder skalierbare Eingabe/Ausgabe-Virtualisierung (skalierbare IOV) zu dynamisch neukonfigurierbaren programmierbaren integrierten Schaltkreisen. Ein Server kann einen Hostprozessor enthalten, der unter Verwendung einer programmierbaren Vorrichtung wie einer programmierbaren Logikvorrichtung (PLD) oder einer feldprogrammierbaren Gatearray-Vorrichtung (FPGA-Vorrichtung) beschleunigt wird.
Die programmierbare Vorrichtung kann einen programmierbaren Ressourcenschnittstellenschaltkreis (PIC) enthalten, der für programmierbare Ressourcenverwaltungsfunktionen verantwortlich ist und kann auch eine oder mehrere Beschleunigerfunktionseinheiten (AFUs) enthalten, die dynamisch neu programmiert werden können, um eine oder mehrere Aufgaben durchzuführen, die vom Hostprozessor ausgelagert wurden. Jede AFU kann ferner logisch in virtualisierte AFU-Kontexte (AFCs) partitioniert sein. Der PIC kann ein statischer Bereich zum Abbilden einer bestimmten PCIe-Funktion (Peripheral Component Interconnect Express) wie einer physischen Funktion oder einer virtuellen Funktion über eine virtualisierte Kommunikationsschnittstelle auf einen oder mehrere AFCs in der programmierbaren Vorrichtung sein. Der Hostprozessor (z. B. Hosttreiber) handhabt Hardware-Entdeckung/Nummerierung und Laden von Vorrichtungstreibern, sodass Sicherheitsisolation und Schnittstellenleistung beibehalten werden.
Der PIC kann zum Beispiel Mechanismen enthalten, die dem Hostprozessor ermöglichen, eine dynamische Anforderungs-/Antwort-Lenkung mit Zugriffsisolierung (z. B. zum Handhaben von vorgeschalteten Arbeitsspeicheranforderungen von einem AFC an den Hostprozessor, nachgeschalteten Arbeitsspeicheranforderungen vom Hostprozessor an einen AFC, AFC-Unterbrechungen, Rücksetzungen auf Funktionsebene für einen AFC usw.) durchzuführen und um eine AFC-Entdeckung und Identifikation (z. B. unter Verwendung einer Vorrichtungsfunktionsliste mit programmierbaren oder virtualisierten Vorrichtungsfunktionsköpfen, Aktualisieren einer AFU/AFC-Kennung unter Verwendung einer empfangenen AFU-Metadatendatei usw.) durchzuführen. Auf diese Weise konfigurierte virtualisierte AFCs auf einer einzigen programmierbaren Vorrichtung können effizient skaliert werden, um mehr als vier virtuelle Maschinen (VMs), die auf dem Hostprozessor/Hostdienst laufen, mehr als 10 VMs, mehr als 20 VMs, mehr als 30 VMs, 10-100 VMs, mehr als 100 VMs oder Hunderte/Tausende von VMs, Prozesscontainern oder Hostprozessen, die auf dem Hostserver laufen, zu unterstützen und an diese zu koppeln. Durch Verwendung des PIC, um dynamische Assoziationen zwischen dem Host-/Gast-OS und den AFCs über verfügbare Plattformfähigkeiten zu erstellen, können die bestimmten Plattformvirtualisierungsfähigkeiten (z. B. SR-IOV oder skalierbare IOV) vom AFU-Entwickler abstrahiert werden, sodass der AFU-Entwickler über Plattformen hinweg eine einheitliche Schnittstelle sieht.
Es ist für Fachleute ersichtlich, dass die vorliegenden Ausführungsbeispiele ohne einige oder alle dieser spezifischen Details ausgeführt werden können. In anderen Fällen wurden wohlbekannte Vorgänge nicht im Detail beschrieben, um die vorliegenden Ausführungsformen nicht unnötig zu verschleiern.
Eine veranschaulichende Ausführungsform eines programmierbaren integrierten Schaltkreises wie einer programmierbaren Logikvorrichtung (PLD) 100, die ausgelegt werden kann, um ein Schaltkreisdesign zu implementieren, ist in 1 gezeigt. Wie in 1 gezeigt, kann die Vorrichtung 100 (z. B. ein feldprogrammierbarer integrierter Gatearray-Schaltkreischip) eine zweidimensionale Anordnung von funktionalen Blöcken enthalten, die Logikanordnungsblöcke (LABs) 110 und andere funktionale Blöcke, wie zum Beispiel Arbeitsspeicherblöcke mit wahlfreiem Zugriff (RAM-Blöcke) 130 und digitale Signalverarbeitungsblöcke (DSP-Blöcke) 120, enthalten. Funktionale Blöcke wie die LABs 110 können kleinere programmierbare Bereiche (z. B. Logikelemente, konfigurierbare Logikblöcke oder adaptive Logikmodule) enthalten, die Eingangssignale empfangen und benutzerdefinierte Funktionen an den Eingangssignalen durchführen, um Ausgangssignale zu erzeugen. Die LABs 110 können auch in größere programmierbare Bereiche gruppiert werden, die manchmal als Logiksektoren bezeichnet werden, die individuell von entsprechenden Logiksektorverwaltungen verwaltet und konfiguriert werden. Die Gruppierung der programmierbaren Logikressourcen auf der Vorrichtung 100 in Logiksektoren, Logikanordnungsblöcke, Logikelemente oder adaptive Logikmodule ist nur illustrativ. Im Allgemeinen kann die Vorrichtung 100 funktionale Logikblöcke einer beliebigen geeigneten Größe und eines beliebigen geeigneten Typs enthalten, die in Übereinstimmung mit einer beliebigen geeigneten Logikressourcenhierarchie organisiert sein können.
Die programmierbare Logikvorrichtung 100 kann programmierbare Arbeitsspeicherelemente enthalten. In die Arbeitsspeicherelemente können unter Verwendung von Eingabe-Ausgabe-Elementen (EAEs) 102 Konfigurationsdaten (auch Programmierdaten oder Konfigurationsbitstrom genannt) geladen werden. Nach dem Laden stellen die Arbeitsspeicherelemente jeweils ein entsprechendes statisches Steuersignal bereit, das den Betrieb eines assoziierten funktionalen Blocks (z. B. der LABs 110, des DSP 120, des RAM 130 oder der Eingabe-Ausgabe-Elemente 102) steuert.
In einem typischen Szenario werden die Ausgaben der geladenen Arbeitsspeicherelemente an die Gatter von Metall-Oxid-Halbleitertransistoren in einem funktionalen Block angelegt, um bestimmte Transistoren ein- oder auszuschalten und dadurch die Logik im funktionalen Block einschließlich der Leitungspfade zu konfigurieren. Programmierbare Logikschaltkreiselemente, die auf diese Weise gesteuert werden können, enthalten Teile von Multiplexern (z. B. Multiplexer, die zum Bilden von Leitungspfaden in Zwischenverbindungsschaltkreisen verwendet werden), Nachschlagetabellen, Logikanordnungen, AND-, OR-, NAND- und NOR-Logikgatter, Durchgangsgatter usw.
Die Arbeitsspeicherelemente können beliebige geeignete flüchtige und/oder nichtflüchtige Arbeitsspeicherstrukturen wie Direktzugriffsarbeitsspeicher(RAM)-Zellen, Sicherungen, Antisicherungen, programmierbare Direktzugriffsarbeitsspeicher-Zellen, maskenprogrammierte und laserprogrammierte Strukturen, Kombinationen dieser Strukturen usw. verwenden. Da Konfigurationsdaten während der Programmierung in die Arbeitsspeicherelemente geladen werden, werden die Arbeitsspeicherelemente manchmal als Konfigurationsarbeitsspeicher, Konfigurations-Direktzugriffsarbeitsspeicher (CRAM) oder programmierbare Arbeitsspeicherelemente bezeichnet. Die programmierbare Logikvorrichtung (PLD) 100 kann ausgelegt sein, ein benutzerdefiniertes Schaltkreisdesign zu implementieren. Der Konfigurations-RAM kann zum Beispiel so programmiert sein, dass die LABs 110, der DSP 120 und der RAM 130, programmierbare Zwischenverbindungsverschaltung (z. B. vertikale Kanäle 140 und horizontale Kanäle 150) und die Eingabe-Ausgabe-Elemente 102 die Implementierung des Schaltkreisdesigns bilden.
Darüber hinaus kann die programmierbare Logikvorrichtung Eingabe-Ausgabe-Elemente (EAEs) 102 zum Steuern von Signalen von der Vorrichtung 100 weg und zum Empfangen von Signalen von anderen Vorrichtungen aufweisen. Die Eingabe-Ausgabe-Elemente 102 können parallele Eingabe-Ausgabe-Verschaltung, serielle Daten-Sende-Empfänger-Verschaltung, differenzielle Empfänger- und Sender-Verschaltung oder eine andere Verschaltung enthalten, die verwendet wird, um einen integrierten Schaltkreis mit einem anderen integrierten Schaltkreis zu verbinden.
Die Vorrichtung 100 kann auch eine programmierbare Zwischenverbindungsverschaltung in Form von vertikalen Leitkanälen 140 (d. h. Zwischenverbindungen, die entlang einer vertikalen Achse der PLD 100 gebildet sind) und horizontalen Leitkanälen 150 (d. h. Zwischenverbindungen, die entlang einer horizontalen Achse der PLD 100 gebildet sind) enthalten, wobei jeder Leitkanal mindestens eine Spur enthält, um mindestens eine Leitung zu leiten. Falls gewünscht kann die Zwischenverbindungsverschaltung Pipelineelemente enthalten und auf die in diesen Pipelineelementen gespeicherten Inhalte kann während des Betriebs zugegriffen werden. Ein Programmierschaltkreis kann zum Beispiel Lese- und Schreibzugriff auf ein Pipelineelement bieten.
Es ist anzumerken, dass andere Leittopologien abgesehen von der in 1 gezeigten Topologie der Zwischenverbindungsverschaltung im Geltungsbereich der vorliegenden Erfindung enthalten sein sollen. Beispielsweise kann die Leittopologie Leitungen enthalten, die diagonal verlaufen oder die horizontal und vertikal entlang unterschiedlicher Teile ihres Verlaufs verlaufen sowie Leitungen, die im Fall von dreidimensionalen integrierten Schaltkreisen auf die Vorrichtungsebene senkrecht stehen, und der Treiber einer Leitung kann sich an einem anderen Punkt befinden als an einem Ende einer Leitung. Die Leittopologie kann globale Leitungen enthalten, die im Wesentlichen die gesamte PLD 100 umspannen, teilweise globale Leitungen, wie Leitungen, die einen Teil der PLD 100 umspannen, gestaffelte Leitungen einer bestimmten Länge, kleinere lokale Leitungen oder eine beliebige andere geeignete Zwischenverbindungsressourcenanordnung.
2 ist ein Diagramm eines beispielhaften Systems, wie dem Server 200, das Hardwarebeschleunigungsressourcen nach einer Ausführungsform einsetzt. Wie in 2 gezeigt kann der Server 200 einen Hostprozessor wie eine Zentralverarbeitungseinheit (CPU) 202 enthalten, die an eine programmierbare Vorrichtung 100 gekoppelt ist. Die programmierbare Vorrichtung 100 kann ausgelegt sein, um Beschleunigungshardwareressourcen für die Host-CPU 202 bereitzustellen und wird manchmal als ein Coprozessor oder eine neukonfigurierbare Beschleunigungsvorrichtung bezeichnet. Der Hostprozessor 202 kann auch über einen Pfad 201 an einen CPU-Arbeitsspeicher 203 gekoppelt sein.
Ein Hostbetriebssystem (Host-OS) 204 ist in die Host-CPU 202 geladen. Das Hostbetriebssystem 204 kann einen Hypervisor 216 implementieren, der die Verwendung von einer oder mehreren virtuellen Maschinen (VM) 210-1 auf dem Hostprozessor 202 ermöglicht. Virtuelle Maschinen sind in sich abgeschlossene virtualisierte Partitionen, die eine unabhängige Hardware-Rechenressource simulieren. Der Hypervisor 216 kann ein Teil der Software oder Firmware sein, der auf dem Hostprozessor 202 läuft, und kann als eine Überwachung für virtuelle Maschinen dienen (manchmal auch als eine Verwaltung für virtuelle Maschinen oder VMM bezeichnet), die die Hardwareressourcen des Systems verwaltet, sodass sie effizient unter den virtuellen Maschinen (VMs) auf dem Server 200 verteilt werden.
Jede virtuelle Maschine kann als eine Gastmaschine bezeichnet werden, die ihr eigenes Gastbetriebssystem (OS) ausführt. In bestimmten Virtualisierungsarchitekturen kann eine bestimmte virtuelle Maschine wie VM0 (eine VM, die das Host-OS 204 hostet) als eine übergeordnete Partition dienen, eine Steuerdomäne („Domäne 0“) oder als eine Rootpartition, die Funktionen auf Maschinenebene, wie Vorrichtungstreiber, Leistungsverwaltung und die Hinzufügung/Entfernung von VMs, verwaltet (z. B. weist VM0 einen Steuerstapel zum Verwalten der Erstellung, Zerstörung und Konfiguration von virtuellen Maschinen auf). Die Steuerdomäne VM0 weist Sonderprivilegien auf, einschließlich der Fähigkeit, direkt auf die Hardware zuzugreifen, handhabt den gesamten Zugriff auf die System-Eingabe-Ausgabefunktionen und interagiert mit allen verbleibenden VMs (z. B. VM1, VM2 usw.). Jede virtuelle Maschine 210-1 kann verwendet werden, um eine oder mehrere Benutzeranwendungen auszuführen. Der Hypervisor 216 präsentiert dem Gast-OS der VM eine virtuelle Betriebsplattform und verwaltet die Ausführung der Gastbetriebssysteme bei gleichzeitigem Teilen virtualisierter Hardwareressourcen. Der Hypervisor 216 kann direkt auf der Hardware des Hosts laufen (als ein Bare-Metal-Hypervisor vom Typ 1) oder kann über einem bestehenden Hostbetriebssystem (als ein gehosteter Hypervisor vom Typ 2) laufen. Wenn gewünscht können zusätzliche Virtualisierungstreiber und Werkzeuge (nicht gezeigt) verwendet werden, um jeder virtuellen Gastmaschine zu helfen, effizienter mit der zugrunde liegenden physischen Hardware der Host-CPU 202 oder den von der programmierbaren Vorrichtung 100 bereitgestellten HardwareBeschleunigungsressourcen zu kommunizieren. Im Allgemeinen kann der Prozessor 202 ausgelegt sein, mindestens zwei VMs, zwei bis zehn VMs, mehr als 10 VMs, 10-100 VMs, mehr als 100 VMs oder eine beliebige geeignete Anzahl von virtuellen Maschinen zu hosten.
Zusätzlich zum Hosten der virtuellen Maschinen 210-1 kann die CPU 202 auch einen oder mehrere (manchmal als Prozesscontainer bezeichnete) Container 210-2 hosten. Im Gegensatz zu einer virtuellen Maschine 210-1, die ein vollständiges Gast-OS mit seiner eigenen Arbeitsspeicherverwaltung Vorrichtungstreiber und Daemons aufweist, nutzen die Container 210-2 das Host-OS 204 gemeinsam und sind relativ leichtgewichtiger und portabler als VMs. Die Container 210-2 sind ein Produkt von „Betriebssystemvirtualisierung“ und ermöglichen, dass mehrere isolierte Benutzerrauminstanzen auf dem gleichen Hostkernel laufen (d. h., der Hostkernel wird unter den verschiedenen Containern gemeinsam genutzt, die jeweils ihre eigene Arbeitslast ausführen). Diese Isolierung garantiert, dass ein beliebiger Prozess im Inneren eines bestimmten Containers keinen anderen Prozess oder keine andere Ressource außerhalb dieses Containers sehen kann.
Ähnlich wie das, was der Hypervisor 216 der VM 210-1 bereitstellt, kann eine Containerverwaltung/-engine 211 im Benutzerraum verwendet werden, um einen oder mehrere Container 210-2 auf dem Server 200 auszuführen. Die Containerverwaltung 211 präsentiert den isolierten Containeranwendungen eine virtuelle Betriebsplattform und verwaltet die Ausführung der isolierten Containeranwendungen bei gleichzeitigem Teilen virtualisierter Hardwareressourcen. Im Allgemeinen kann der Prozessor 202 ausgelegt sein, mindestens zwei Container, zwei bis zehn Container, mehr als 10 Container, 10-100 Container, 100-1000 Container, Tausende von Containern oder eine beliebige geeignete Anzahl von Containern zu hosten, die den gleichen Host-OS-Kernel gemeinsam nutzen. Als Beispiele kann die Host-CPU 202 ausgelegt sein, Prozesscontainer wie Docker, Linux-Container, Windows-Server-Container und/oder andere Arten von Prozesscontainern zu hosten. In anderen geeigneten Ausführungsformen kann die Host-CPU 202 ausgelegt sein, Maschinencontainer wie Hyper-V-Container zu hosten, die von Microsoft Corporation entwickelt wurden, Kata-Container, die von der OpenStack Foundation verwaltet werden, und/oder andere Arten von leichtgewichtigen virtuellen Maschinen.
Ferner kann die CPU 202 einen oder mehrere Prozesse 210-3 (die manchmal als Host- oder Anwendungsprozesse bezeichnet werden) hosten, was einem Container 210-2 in dem Sinn ähnlich ist, dass ein Prozess 210-3 seinen eigenen Adressraum, Programm, CPU-Zustand und Prozesstabelleneintrag aufweist. Im Gegensatz zum Container 210-2, der ein isoliertes Programm mit allen seinen Abhängigkeiten in seiner Dateisystemumgebung einkapselt, kapselt der Prozess 210-3 keine der abhängigen, gemeinsam genutzten Bibliotheken in der Dateisystemumgebung ein. Der Prozess 210-3 kann über dem OS ausgeführt werden. Im Allgemeinen kann der Prozessor 202 ausgelegt sein, mindestens zwei Prozesse 210-3, zwei bis zehn Prozesse, mehr als 10 Prozesse, 10-100 Prozesse, 100-1000 Prozesse, Tausende von Prozessen oder eine beliebige geeignete Anzahl von Prozessen auf dem Kernel zu hosten.
Im Allgemeinen kann die Software, die auf der Host-CPU 202 läuft, unter Verwendung von Softwarecode implementiert sein, der auf nicht transitorischen computerlesbaren Speichermedien (z. B. greifbaren computerlesbaren Speichermedien) gespeichert ist. Der Softwarecode kann manchmal als Software, Daten, Programmanweisungen, Anweisungen, Skript oder Code bezeichnet werden. Die nicht transitorischen computerlesbaren Speichermedien können nichtflüchtigen Arbeitsspeicher wie nichtflüchtigen Direktzugriffarbeitsspeicher (NVRAM), eine oder mehrere Festplattenlaufwerke (z. B. Magnetlaufwerke oder Festkörperlaufwerte), eine oder mehrere entfernbare Flash-Laufwerke oder andere entfernbare Medien oder Ähnliches enthalten. Software, die auf den nicht transitorischen computerlesbaren Speichermedien gespeichert ist, kann auf der Verarbeitungsverschaltung des Hostprozessors 202 ausgeführt werden.
Der Hostprozessor 202 kann über eine Hostschnittstelle wie die Hostschnittstelle 230 mit der programmierbaren Vorrichtung 100 kommunizieren. Die Hostschnittstelle 230 kann eine Computerbusschnittstelle wie die von der PCI Special Interest Group oder PCI-SIG entwickelte PCIe-Schnittstelle (Peripheral Component Interconnect Express), Cache Coherent Interconnect for Accelerators (CCIX), Gen-Z, Open Coherent Accelerator Processor Interface (OpenCAPI), Intel Accelerator Link (IAL), NVLink von Nvidia oder andere Computerbusschnittstellen sein. Im Allgemeinen kann die Hostschnittstelle 230 unter Verwendung anderer Mehrfachdatenspuren (z. B. mindestens 2 Spuren, mindestens 4 Spuren, mindestens 8 Spuren, mindestens 16 Spuren, mindestens 32 Spuren, mindestens 64 Spuren usw.), einer einzelnen Datenspur, einem parallelen Datenbus, einem seriellen Datenbus oder anderen Computerbusstandards implementiert sein, die Datenübertragungsraten von mindestens 250 MB/s (Megabytes pro Sekunde), 500 MB/s, 1 GB/s (Gigabytes pro Sekunde), 5 GB/s, 10 GB/s, 16 GB/s, 32 GB/s, 64 GB/s oder mehr unterstützen können.
Ein einzelner Hostprozessor 202, der die virtuellen Maschinen 210-1, Container 210-2, Hostprozesse 210-3 und andere Entitäten auf Softwareebene ausführt (die manchmal kollektiv als „Aufgabenauslagerungsmodule“ bezeichnet werden, die Aufgaben an die programmierbare Beschleunigervorrichtung 100 auslagern), muss die Hostschnittstelle 230 zwischen den verschiedenen Arten von Aufgabenauslagerungsmodulen teilen. Um dies zu unterstützen, hat die PCI-SIG eine Erweiterung zur PCIe-Spezifikation ausgegeben, die Einzel-Root-Eingabe/Ausgabe-Virtualisierung (SR-IOV) genannt wird, die den unterschiedlichen virtuellen Maschinen, Containern und Softwareprozessen in einer virtuellen Umgebung ermöglichen, eine einzelnen PCIe-Hardwareschnittstelle gemeinsam zu nutzen. Die SR-IOV-Spezifikation ermöglicht, dass eine einzelne Rootfunktion (z. B. ein Ethernetanschluss) als mehrere, separate physische Vorrichtungen erscheinen, jede mit ihrem eigenen PCIe-Konfigurationsraum. Eine physische Vorrichtung mit SR-IOV-Fähigkeiten kann ausgelegt sein, im PCI-Konfigurationsraum als mehrere Funktionen an einem virtuellen Bus zu erscheinen. Wenn gewünscht können die hierin beschriebenen Techniken auch auf skalierbare IOV (SIOV) angewandt werden, die von Intel Corporation entwickelt wurde, oder auf andere Vorrichtungsvirtualisierungsstandards.
Skalierbare IOV von Intel ist eine PCIe-basierte Virtualisierungstechnik, die eine stark skalierbare gemeinsame Hochleistungsnutzung von E/A-Vorrichtungen über isolierte Domänen ermöglicht, während die Kosten und Komplexität für Endpunktvorrichtungs-Hardware zur Unterstützung derartiger skalierbarer gemeinsamer Nutzung begrenzt werden. Abhängig vom Nutzungsmodell können die isolierten Domänen virtuelle Maschinen, Prozesscontainer, Maschinencontainer oder Anwendungsprozesse sein. Im Gegensatz zum grobkörnigen Vorrichtungspartitionierungsansatz von SR-IOV, um mehrere VFs auf einer PF zu erstellen, ermöglicht skalierbare IOV virtuelle Vorrichtungen, die die Hardwareunterstützung zur gemeinsamen Vorrichtungsnutzung einsetzen, flexible mit feinerer Granularität zusammenzusetzen. Für die Leistung kritische Vorgänge auf der zusammengesetzten virtuellen Vorrichtung werden direkt auf die zugrunde liegende Vorrichtungshardware abgebildet, während nicht kritische Vorgänge durch vorrichtungsspezifische Zusammensetzungssoftware im Host emuliert werden.
SR-IOV definiert zwei Arten von durch den Host zuweisbaren Schnittstellen oder PCI-Funktionen, die die Hardware-/Software-Schnittstelle über die programmierbare Vorrichtung 100 und das Host-OS 204 umspannen: (1) physische Funktionen und (2) virtuelle Funktionen. Eine physische Funktion (PF) wie PF 232 ist eine vollfunktionsfähige PCIe-Funktion, die wie typische PCI-Vorrichtungen entdeckt, verwaltet und konfiguriert wird, und ihren eigenen unabhängigen Satz von Basisadressregistern (BARs) aufweist. Die physische Funktion 232 kann von einem physischen Funktionentreiber 206 verwaltet werden, der ein Teil des Kernelraums des Host-OS 204 sein kann. Die physische Funktion 232 konfiguriert und verwaltet die SR-IOV-Funktionalität durch Zuweisen assoziierter virtueller Funktionen (VFs) 234. Die physische Funktion 232 wird deshalb manchmal als eine „privilegierte“, durch den Host zuweisbare Schnittstelle bezeichnet. Eine einzelne physische Funktion 232 kann mehr als 10, mehr als 100, bis zu 256, mehr als 1000, mehr als 60000, mehr als 100000 oder mindestens eine Million assoziierter virtueller Funktionen 234 aufweisen. Nach Wunsch kann jeder Host auch mehr als eine assoziierte physische Funktion 232 aufweisen.
Im Gegensatz zur physischen Funktion 232 sind die virtuellen Funktionen 234 leichtgewichtige PCIe-Funktionen (d. h. weniger komplex als eine PF), die nur ihr eigenes Verhalten steuern können. Jede virtuelle Funktion ist von den Ressourcen einer assoziierten physischen Funktion abgeleitet und teilt diese. Jede virtuelle Funktion 234 kann auch ihren eigenen unabhängigen Satz von Basisadressregistern (BARs) aufweisen und kann von einem virtuellen Funktionstreiber 214 (der Teil des Kernelraums des Gast-OS ist, das auf einer der virtuellen Maschinen 210-1 läuft), einem Benutzermodustreiber (der Teil des Benutzerraums des Programms ist, das auf einem der Container läuft) oder einem Benutzermodustreiber (der Teil des Benutzerraums des Programms ist, das als Teil einer der Anwendungsprozesse 210-3 läuft) verwaltet werden. Anders ausgedrückt kann eine virtuelle Funktion auch einem Container 210-2 zugewiesen werden, um eine Hardwareauslagerung zu ermöglichen. In anderen Szenarien werden die virtuellen Funktions-BARs auf den Adressraum des Prozesses 210-3 abgebildet, um eine Hardwarevorlage zu ermöglichen. Im Gegensatz zur physischen Funktion, die als eine privilegierte, durch den Host zuweisbare Schnittstelle angesehen wird, wird die virtuelle Funktion 234 deshalb manchmal als eine „nicht privilegierte“, durch den Host zuweisbare Schnittstelle bezeichnet. Im Allgemeinen kann jede virtuelle Maschine 210-1, jeder Container 210-2 oder jeder Prozess 210-3 auf eine oder mehrere virtuelle Funktionen abgebildet werden. Auf diese Weise konfigurierte virtuelle Funktionen weisen eine fast native Leistung auf und bieten eine bessere Leistung als para-virtualisierte Treiber und emulierter Zugriff und erhöhen auch die virtualisierte Gastdichte auf Hostservern innerhalb eines Rechenzentrums.
Die programmierbare Vorrichtung 100 kann Logik enthalten, um die physische Funktion 232 und die virtuellen Funktionen 234 zu implementieren. Weiterhin auf 2 Bezug nehmend, kann die programmierbare Vorrichtung 100 einen programmierbaren Ressourcenschnittstellenschaltkreis (PIC) 250 enthalten, der über eine virtualisierte Kommunikationsschnittstelle 254 an eine oder mehrere Beschleunigerfunktionseinheiten (AFUs) gekoppelt ist. Der Schnittstellenschaltkreis 250 (manchmal als eine FPGA-Schnittstelleneinheit oder FIU bezeichnet) ist als ein statischer Logikabschnitt konfiguriert, der grundlegende Infrastrukturfunktionalität wie Arbeitsspeicherzugriffsisolierung, Vorrichtungsverwaltung und Host-/Arbeitsspeicher-Schnittstellen bereitstellt.
Die programmierbare Vorrichtung 100 kann auch einen oder mehrere benutzerprogrammierbare Bereiche enthalten, die dynamisch und teilweise auf Grundlage von Benutzeranforderungen oder des Arbeitslastbedarfs neu konfiguriert werden können. Der Prozess, bei dem nur eine Teilmenge der programmierbaren Logik auf der Vorrichtung 100 geladen wird, wird manchmal als eine „teilweise Neukonfiguration“ bezeichnet. Jeder dieser Bereiche für teilweise Neukonfiguration (PR) kann als ein „Schlitz“ oder Container dienen, in den eine Beschleunigerfunktionseinheit (AFU) 252 geladen werden kann. Die Beschleunigerfunktionseinheit 252 wird zum Auslagern einer Rechenoperation für eine Anwendung von der Host-CPU 202 verwendet, um die Leistung zu verbessern. Wie oben beschrieben, ist die physische Funktion 232 hauptsächlich für Verwaltungsfunktionen verantwortlich. Deshalb kann die dynamische Programmierung der AFU 252 durch den physischen Funktionstreiber beaufsichtigt werden. Das Beispiel von 2, in dem zwei AFUs 252 in die programmierbare Vorrichtung 100 geladen sind, ist nur veranschaulichend. Im Allgemeinen kann die Vorrichtung 100 mit nur einer AFU, mehr als zwei AFUs, 2-10 AFUs, mehr als 10 AFUs, 10-100 AFUs oder einer beliebigen geeigneten Anzahl von Beschleunigerfunktionseinheiten versehen sein. Jede der AFUs 252 auf einer Vorrichtung 100 können mit der gleichen oder mit einer unterschiedlichen Anzahl von AFCs 252 versehen sein.
In Übereinstimmung mit einer Ausführungsform kann ein AFU-Bereich 252 ferner logisch in unterschiedliche AFU-Kontexte (AFCs) 256 unterteilt werden, von denen jeder als eine separate Beschleunigungseinheit dient, die einer entsprechenden individuellen Softwareauslagerungseinheit wie der VM 210-1, dem Container 210-2 oder dem Hostprozess 210-3 unabhängig zugewiesen werden kann. Im Allgemeinen kann jede Aufgabenauslagerungsentität auf eine oder mehrere virtuelle Funktionen abgebildet werden.
Jeder AFC 256 kann eine Scheibe des gleichen Beschleunigers (z. B. als Teil der gleichen AFU), eines vollständig anderen Beschleunigers (z. B. als Teil von unterschiedlichen AFUs), eines Satzes von Pfortenregistern zum Ermöglichen der Einreichung von Arbeit an gemeinsam genutzte Beschleunigerressourcen oder eine andere logische Aufteilung sein. Eine Komprimierungs-AFU mit acht Engines könnte zum Beispiel die AFCs als räumlich gemeinsam genutzt freigeben (d. h., wobei jede der 8 Komprimierungsengines als eine unterschiedliche AFC freigegeben wird) oder zeitlich gemeinsam genutzt (d. h., wobei eine Gruppe von Pforten-/Türklingelregistern freigegeben wird, die eine Deskriptoreinreichung an tatsächliche Engines ermöglicht, die unter unterschiedlichen AFCs zeitlich gemeinsam genutzt oder zeitlich gemultiplext werden).
Im Allgemeinen werden alle AFCs 256 innerhalb einer AFU 252 zusammen neu konfiguriert und sind über eine einzige Kommunikationsschnittstelle 254 mit dem PIC 250 verbunden. Der PF-Treiber im Host nummeriert die programmierbare Vorrichtung 100 und verwaltet den PIC 250. Die Hosttreiber identifizieren die unterschiedlichen AFCs gemeinsam und erzeugen Assoziationen zwischen der Hardware, die mit jedem AFC assoziiert ist, und der/dem entsprechenden Benutzeranwendungs-Software/-Treiber. Als ein Beispiel kann ein AFC 256 auf eine virtuelle Funktion 234 oder eine physische Funktion 232 abgebildet werden. Dies ist nur illustrativ. Als ein weiteres Beispiel können mehrere AFCs 256 (die ein Teil der gleichen AFU oder verschiedener AFUs sein können) auf eine VF 234 abgebildet werden. Falls gewünscht kann ein AFC 256 auch auf zwei oder mehr virtuelle Funktionen abgebildet werden.
Das oben beschriebene Beispiel, bei dem ein AFC auf eine physische PCIe-Funktion oder eine virtuelle PCIe-SR-IOV-Funktion abgebildet wird, ist nur illustrativ. Im Allgemeinen kann ein AFC auf eine beliebige, durch einen Host zuweisbare Schnittstelle wie eine zuweisbare Vorrichtungsschnittstelle (ADI) der skalierbaren IOV oder andere, durch einen Host zuweisbare Schnittstellen abgebildet werden, die mit Nicht-PCIe-Hostschnittstellen assoziiert sind.
Um die logische Unterteilung einer AFU 252 in mehrere AFCs 256 zu unterstützen, kann die Kommunikationsschnittstelle 254 virtualisiert werden, um eine gemeinsame AFU-Nutzung zu unterstützen. Insbesondere können alle Transaktionen, die über die Schnittstelle 254 laufen, mit einer Kontextkennungs(ID)-Markierung markiert werden. Diese Kontext-ID-Markierung wird verwendet, um eine richtige Leitung von Anforderungen und Antworten zwischen den Softwareanwendungen auf dem Host und den AFCs sicherzustellen sowie um eine Sicherheitsisolierung bereitzustellen.
In einer geeigneten Anordnung kann die Kontext-ID-Markierung verwendet werden, um eine Adressenisolierung zwischen unterschiedlichen AFC-Arbeitsspeicheranforderungen bereitzustellen. Alle „vorgeschalteten“ Anforderungen von einem AFC 256 (z. B. Arbeitsspeicheranforderungen von einem AFC zur Host-CPU) sind mit einer context_id markiert, die den Namensraum jeder Arbeitsspeicheranforderung auf <context_id, Adresse> erweitert, wobei Adresse die physische Adresse oder die virtuelle Adresse repräsentieren kann. Der PIC 250 kann die spezifische context_id unter Verwendung einer Kontextabbildungstabelle 260 auf einen plattformspezifischen Identifikator abbilden. Nachdem SR-IOV in der physischen Funktion aktiviert ist, kann durch die Bus-, Vorrichtungs- und Funktionsnummer dieser virtuellen Funktion (manchmal kollektiv als die „BDF-Nummer“ bezeichnet) auf den PCI-Konfigurationsraum jeder virtuellen Funktion zugegriffen werden.
3A zeigt eine Kontextabbildungstabelle 260-1, wobei die context_id einer vorgeschalteten Arbeitsspeicheranforderung als ein Index verwendet werden kann, um eine entsprechende PCIe-{Bus, Vorrichtung, Funktion}-Nummer nachzuschlagen. Jeder AFC weist eine eindeutige context_id auf, die auf eine entsprechende PCIe-Funktion in Übereinstimmung mit der zugewiesenen BDF-Nummer abgebildet ist. Wie oben beschrieben können mehrere AFCs auf eine virtuelle Funktion abgebildet sein. Die entsprechende BDF-Nummer in Tabelle 260-1 kann an das PCIe-Transportschichtpaket angehängt werden und an den Hostprozessor zur weiteren Verarbeitung gesendet werden. Falls der Server 200 eine skalierbare IOV-Unterstützung (SIOV-Unterstützung) oder eine Unterstützung für gemeinsam genutzten virtuellen Arbeitsspeicher (SVM) implementiert, dann kann die context_id in der vorgeschalteten Arbeitsspeicheranforderung auf eine entsprechende PCIe-{Bus, Vorrichtung, Funktion, PASID}-Nummer abgebildet sein, wobei PASID die Prozessadressraum-ID ist.
Auf jeden Fall bietet der PIC 250 jeder AFU 252 ein Niveau an Abstraktion und ist für das Umwandeln des Arbeitsspeicheranforderungs-Namensraums verantwortlich. Ein derartiges Betreiben einer virtualisierten Beschleunigungsplattform bietet den technischen Vorteil des Entkoppelns einer Kommunikationssemantik einer AFU von der zugrunde liegenden Plattformsemantik (z. B. von einer PCIespezifischen Semantik). Im Allgemeinen sollte die context_id hinreichend breit sein, um nur die Anzahl von unterstützten AFCs abzudecken, was wahrscheinlich sehr viel geringer als die Plattformnamensraumkennungsbreite ist. Ein Reduzieren oder Minimieren der Größe oder Bitbreite der context_id kann wertvollen Leitungsraum auf der Vorrichtung 100 sparen.
Eine Antwort von der Host-CPU auf eine vorgeschaltete Anforderung von einem AFC oder einer MMIO-Transaktion, die vom Host initiiert wurde, muss zurück zu diesem AFC geleitet werden. Dieser Leitmechanismus kann davon abhängen, wie die AFCs mit den physischen und virtuellen PCIe-Funktionen verbunden sind. In einem ersten Modus sind zumindest einige oder möglicherweise alle der AFCs mit der physischen Funktion assoziiert und es wird auf sie über die physische Funktion zugegriffen. Der erste Modus wird deshalb manchmal als der „PF-Modus“ bezeichnet. In einem zweiten Modus ist jeder AFC mit einer einzelnen virtuellen Funktion assoziiert und die gesamten Hostkommunikationen für einen AFC geschehen durch die assoziierte virtuelle Funktion. Der zweite Modus wird deshalb manchmal als der „VF-Modus“ bezeichnet. Das System kann auch in einem dritten (gemischten) Modus betrieben werden, wobei einige AFCs auf die physische Funktion abgebildet sind, während andere AFCs auf entsprechende virtuelle Funktionen abgebildet werden.
Im PF-Modus wird die BDF-Nummer der physischen Funktion für mehrere AFCs verwendet, sodass die BDF-Nummer alleine die context_id nicht bestimmen kann. Um dieses Problem im PF-Modus zu behandeln, weist PCIe einen Mechanismus auf, wobei eine Anforderung mit einer Markierung assoziiert werden kann und die Antwort garantiert die gleiche Markierung zurückgibt. Die context_id der Anforderung kann zum Beispiel in einer internen Tabelle (siehe z. B. Tabelle 262 in 2) gespeichert werden, die durch die PCIe-Markierung indiziert wird, wenn die vorgeschaltete Anforderung gesendet wird. Beim Verarbeiten der Antwort kann die zurückgegebene PCIe-Markierung verwendet werden, um in der internen Tabelle 262 nachzuschlagen, um die richtige context_id abzurufen. Diese interne Tabelle muss nicht gegenüber der Hostsoftware freigelegt sein und kann vom PIC 250 aktualisiert und gelesen werden.
Im VF-Modus kann der PIC 250 mit der gegebenen PCIe-BDF-Nummer der virtuellen Funktion die context_id des AFC eindeutig ermitteln. Für „nachgeschaltete“ Anforderungen (z. B. Arbeitsspeicheranforderungen von der Host-CPU zurück zu einem AFC oder eine von der Host-CPU initiierte MMIO-Transaktion) kann eine Umkehrkontextabbildungstabelle, wie die Umkehrkontextabbildungstabelle 260-2 von 3B verwendet werden, um eine plattformspezifische Kennung (z. B. eine BDF-Nummer mit oder ohne PASID) auf eine entsprechende context_id abzubilden. Die Umkehrkontextabbildungstabelle 260-2 kann vom Host-PCIe-Treiber (z. B. dem PF-Treiber 206) programmiert sein, wenn die gesamte Vorrichtung 100 stillgelegt ist. Alternativ kann eine feinere Programmierung individueller AFC-Einträge in der Tabelle 260-2 implementiert sein, wenn der bzw. die entsprechende(n) AFC(s) stillgelegt ist bzw. sind.
Einige Ausführungsformen können den AFC-Namensraum zum Hostzugriff auf die physische Funktion abbilden. Im PF-Modus (d. h., wenn alle AFCs auf die physische Funktion abgebildet sind) verwenden alle Anforderungen wie in den Arbeitsspeicher abgebildete Eingabe/Ausgabe(MMIO)-Anforderungen die gleiche plattformspezifische Kennung. In diesem Fall muss der MMIO-Adressbereich der physischen Funktion groß genug sein, um den gesamten MMIO-Raum über alle AFCs hinweg abzubilden. Ein zusätzlicher Adressendecodierer, wie ein Adressendecodierer 264, der als Teil des PIC 250 vorgesehen ist, kann dann verwendet werden, um die context_id von einer bestimmten MMIO-Adresse, die mit dem BAR der physischen Funktion assoziiert ist, zu decodieren. Falls gewünscht kann der Adressendecodierer 264 auch als Teil einer AFU zum Decodieren von AFU-Adressen und/oder als Teil eines AFC zum Decodieren von AFC-Adressen gebildet sein. Im gemischten Modus, in dem einige AFCs auf die physische Funktion abgebildet sind und andere AFCs auf virtuelle Funktionen abgebildet sind, kann bzw. können ein Speichern einer Markierung in der internen Tabelle 262, Verwenden einer Umkehrabbildungstabelle, um plattformspezifische Kennungen zu identifizieren, Verwenden des Adressendecodierers 264, um eine MMIO-Adresse zu decodieren, und/oder eine Kombination dieser Techniken gleichzeitig verwendet werden.
Ähnlich wie das Ausgeben von vorgeschalteten Arbeitsspeicheranforderungen können AFCs optional Unterbrechungen ausgeben. Unterbrechungsanforderungen von einem AFC werden auch mit einer context_id markiert, was auf eine ähnliche Weise wie der in Verbindung mit 3A gezeigte und beschriebene vorgeschaltete Anforderungsablauf gehandhabt wird. Anders ausgedrückt kann eine Unterbrechungsanforderung eine context_id zum Nachschlagen einer entsprechenden plattformspezifischen Kennung in Übereinstimmung mit der Kontextabbildungstabelle 260-1 aufweisen.
Bestimmte Spezifikationen wie SR-IOV erfordern, dass Vorrichtungen eine Rücksetzung auf Funktionsebene (FLR) pro virtueller Funktion unterstützen. In einigen Szenarien, wie zum Beispiel während des PF-Modus oder des gemischten Modus, könnte es Vorrichtungsverwaltungsregister geben, die eingesetzt werden, um Rücksetzungen auf Kontextebene (CLR) für einen oder mehrere AFCs auszulösen. Die Rücksetzung auf Kontextebene könnte auch über eine Rücksetzung auf Funktionsebene initiiert werden. Darüber hinaus erfordern Aktualisierungen an der Kontextabbildungstabelle 260 auch einen Weg, um entsprechende betroffene AFCs stillzulegen. 4 ist ein Ablaufdiagramm von illustrativen Schritten zum Durchführen einer Rücksetzung auf Kontextebene für einen bestimmten AFC.
Bei Schritt 400 kann eine virtuelle Funktion eine Rücksetzung auf Kontextebene (CLR) an einem bestimmten AFC initiieren. Bei Schritt 402 kann ein Front-End-Modul im PIC 250 verwendet werden, um Transaktionen zu filtern, die auf den bestimmten AFC abzielen. Der PIC 250 kann zum Beispiel angewiesen werden, alle vorgeschalteten Anforderungen vom angegebenen AFC ordnungsgemäß zu verwerfen, zu entleeren, zu löschen oder anderweitig zu handhaben und/oder alle nachgeschalteten Anforderungen, die auf den bestimmten AFC abzielen, ordnungsgemäß zu verwerfen/zu entleeren/zu löschen oder anderweitig zu handhaben.
Bei Schritt 404 kann die AFC-Rücksetzung unter Verwendung des PIC 250 beginnen, eine CLR-Nachricht an den bestimmten AFC zu senden. Als Reaktion auf das Empfangen der CLR-Nachricht wird erwartet, dass der bestimmte AFC innerhalb von X Zyklen (z. B. innerhalb von 1-2 Taktzyklen, 1-5 Taktzyklen, 1-10 Taktzyklen, 10-100 Taktzyklen usw.) aufhört, Anforderungen auszugeben, die mit der spezifischen context_id markiert sind. Bei Schritt 406 kann der AFC optional eine CLR-Bestätigung an den PIC 250 zurückgeben.
Bei Schritt 408 kann der PIC 250 warten, bis alle ausstehenden Transaktionen vom spezifischen AFC entleert sind (bis z. B. alle anstehenden vorgeschalteten Anforderungen eine Antwort von der Host-CPU erhalten haben und bis alle anstehenden nachgeschalteten Anforderungen eine Antwort vom AFC erhalten haben oder abgelaufen sind). Bei Schritt 410 kann die Front-End-Transaktionsfilterung des PIC 250, die in Verbindung mit Schritt 402 beschrieben wurde, entfernt oder angehalten werden.
Bei Schritt 412 kann die CLR-Operation dadurch beendet werden, dass dem spezifischen AFC ermöglicht wird, das Senden und Empfangen von Anforderungen zu und von der Host-CPU wiederaufzunehmen. Um eine bestimmte CLR zu beenden, kann der PIC 250 eine CLR-Endenachricht an den spezifischen rückgesetzten AFC senden, der spezifische rückgesetzte AFC kann eine CLR-Endenachricht an den PIC 250 senden, oder der PIC 250 kann eine neue CLR-Anforderung an einen anderen AFC senden (unter der Annahme, dass der PIC 250 nur eine AFC-Rücksetzung zu einem bestimmten Zeitpunkt handhaben kann).
Die Schritte von 4 sind nur illustrativ und sollen den Geltungsbereich der vorliegenden Ausführungsformen nicht einschränken. Falls gewünscht können mindestens einige der bestehenden Schritte verändert oder weggelassen werden; einige der Schritte können parallel ausgeführt werden; zusätzliche Schritte können hinzugefügt oder eingefügt werden; und die Reihenfolge bestimmter Schritte kann umgekehrt oder geändert werden. Falls gewünscht können andere Wege zum Implementieren einer CLR für eine Mehrkontext-AFU verwendet werden.
In Übereinstimmung mit einer anderen Ausführungsform kann die programmierbare Vorrichtung 100 ausgelegt sein, eine Vorrichtungsfunktionsliste (DFL) zu pflegen, die der Host-CPU 202 oder der auf der Host-CPU 202 laufenden Software ermöglicht, zu entdecken, zu nummerieren und zu identifizieren, welche AFCs 256 auf der programmierbaren Beschleunigervorrichtung 100 existieren. Insbesondere kann die physische Funktion auf dem Hostprozessor die Vorrichtungsfunktionsliste verwalten, neu programmieren oder aktualisieren. Die Vorrichtungsfunktionsliste bildet den Zugriff auf bestimmte AFCs auf passende Benutzeranwendungen ab, die auf der Host-CPU laufen (um z. B. zu ermöglichen, dass verschiedene AFCs innerhalb einer einzigen AFU von mehreren Benutzeranwendungen gemeinsam genutzt werden). Eine DFL ist eine Datenstruktur, die eine verkettete Liste mit Vorrichtungsfunktionsköpfen (DFHs) enthält. Jeder DFH beschreibt eine bestimmte Unterfunktion der Vorrichtung 100. Jeder DFH bietet zum Beispiel Identifikationsinformationen, sodass die entsprechende Funktion von der Hostsoftware entdeckt werden kann, wobei sowie relevante Ressourcen und Attribute in Verbindung mit dieser Funktion beschrieben werden. Wie unten in Verbindung mit 5-8 beschrieben wird, kann eine einzelne AFU einen oder mehrere zugehörige DFHs aufweisen.
5 ist ein Diagramm einer illustrativen Vorrichtungsfunktionsliste 500 aus der Perspektive einer physischen Funktion im PF-Modus, im VF-Modus oder im gemischten Modus. In einer geeigneten Anordnung kann die Host-CPU 202 an die programmierbare Vorrichtung 100 unter Verwendung eines in den Arbeitsspeicher abgebildeten E/A(MMIO)-Schemas ankoppeln. Im Allgemeinen ist die Vorrichtungsfunktionsliste in der programmierbaren Logik der Vorrichtung 100 implementiert und wird dem Host über ein Basisadressregister (BAR) dargelegt. Wie in 5 gezeigt, ist das MMIO-Basisadressregister (BAR) mit den physischen Funktionsabbildungen auf alle der DFH-Knoten assoziiert und weist eine komplette Ansicht des Beschleunigersystems auf. Der PF-Treiber kann die Vorrichtungsfunktionsliste durchgehen, um alle Anschlüsse und AFC-DFHs zu nummerieren. Insbesondere zeigt das PF-MMIO-BAR auf einen PIC-DFH der Verwaltungsregister 510 darlegt. Die Register 510 können zum Beispiel Register für Telemetrie (z. B. Register zum Darlegen von Fehlern und Ereignissen an den Host zu Überwachungs- und Verwaltungszwecken), Register zum Neuprogrammieren bestimmter AFU-Schlitze, Register, die rücksetzbare Leistungszähler und Metriken enthalten und andere, zur allgemeinen PIC-Verwaltung gedachte Register enthalten.
Der PIC-DFH kann auf einen Anschluss-0-DFH zeigen, der Anschluss-Steuerregister 512 darlegt. Die Register 512 sind Register auf Anschlussebene zum Steuern der Schnittstelle zwischen dem PIC und einem entsprechenden PR-Bereich/Schlitz. Die Register 512 können zum Beispiel Register zum Programmieren von Anschluss-0, Register zum Steuern der Art von Eintritts- und Austritts-Datenpaketen durch Anschluss-0, Register zum Signalisieren von Fehlern, Register, die für Debug- oder Fehlersuchzwecke verwendet werden, oder andere für für Anschluss-0 spezifische Verwaltungsfunktionen gedachte Register enthalten. Falls gewünscht kann der PIC-DFH auch auf DFHs zeigen, die mit anderen Anschlüssen assoziiert sind (z. B. Anschluss-1-DFH, Anschluss-2-DFH, Anschluss-3, DFH, usw.). Der Anschluss-0-DFH kann auch verwendet werden, um eine AFU-Kennung (ID) und die Position (z. B. in Übereinstimmung mit dem MMIO-Offset und der MMIO-Länge) von entsprechenden AFU-Registern in der Benutzerpartition zu lesen. Die AFU-ID kann dabei helfen, zu identifizieren, was in jede AFU geladen ist.
Der Anschluss-O-DFH kann auf eine Reihe von AFC-DFHs zeigen (z. B. auf einen ersten AFC-0-DFH, der auf einen zweiten AFC-1-DFH zeigt, ..., der auf einen letzten AFC-M-DFH zeigt). Jeder dieser AFC-DFHs kann verwendet werden, um die AFC-ID und die Position (z. B. unter Verwendung des MMIO-Offsets und der Längeninformationen) von entsprechenden AFC-Registern 516 in der Benutzerpartition zu lesen (siehe auch die Register 516 in 2). Der MMIO-Offset, der mit dem AFC-0-DFH assoziiert ist, kann zum Beispiel als ein Zeiger auf den Start des MMIO-Bereichs dieses AFCs im PF-MMIO-BAR dienen, wie durch den gepunkteten Pfad 520 angezeigt. Als ein weiteres Beispiel dient der MMIO-Offset, der mit dem AFC-1-DFH assoziiert ist, als ein Zeiger auf den Start des MMIO-Bereichs dieses AFCs im PF-MMIO-BAR, wie durch den gepunkteten Pfad 522 angezeigt. Als noch ein weiteres Beispiel kann der MMIO-Offset, der mit dem AFC-M-DFH assoziiert ist, als ein Zeiger auf den Start des MMIO-Bereichs dieses AFCs im PF-MMIO-BAR dienen, wie durch den gepunkteten Pfad 524 angezeigt.
Die AFC-ID kann dabei helfen, die Funktionalität zu identifizieren, die von jedem AFC bereitgestellt wird. Die AFC-ID kann zum Beispiel dabei helfen, zu identifizieren, ob ein bestimmter AFC eine Sicherheitsfunktion (z. B. eine Verschlüsselungs-/Entschlüsselungsengine), eine Speicherfunktion (z. B. eine Komprimierungs-/Dekomprimierungs-Engine), eine Funktion für maschinelles Lernen (z. B. eine faltende neuronale Netzwerkengine oder eine tiefe neuronale Netzwerkengine), eine Vernetzungsfunktion (z. B. eine Netzwerkfunktionsvirtualisierungsengine) usw. implementiert.
Die AFU/AFC-ID, der MMIO-Offset, die MMIO-Länge und andere Steuer-/Statusinformationen, die mit jedem der DFHs assoziiert sind, können in programmierbaren Registern 514 gespeichert sein. Die Register 514 und 516 können Lese-/Schreibzugriff von der physischen Funktion aufweisen (die AFU-/AFC-Kennung und Positionsinformationen können z. B. von der physischen Funktion während teilweiser Neukonfigurationsoperationen oder während eines VF-Zuweisungs-/Entfernungsprozesses aktualisiert werden). Die programmierbaren Register 514 können als ein Teil des PIC 250 gebildet sein (siehe auch Register 514 in 2). Die Verwendung des PF-Treibers, um die Vorrichtungsfunktionsliste 500 auf diese Weise zu konfigurieren, ermöglicht dem Gesamtsystem, Verknüpfungen zwischen der Hardware der AFU und den Softwarebenutzeranwendungen zu erstellen und Verknüpfungen zwischen der Hardware der AFCs und den Software-AFC-Anwendungen (z. B. den virtuellen Funktionstreibern und den Benutzermodustreibern) zu erstellen.
Die physische Funktion arbeitet in einem physischen Host-Adressraum (HPA-Raum). Im Gegensatz dazu arbeitet die virtuelle Funktion, die einer VM oder einem Container zugewiesen werden kann, im physischen Gast-Adressraum (GPA-Raum). Deshalb kann der MMIO-Offset aus der Perspektive der PF vom MMIO-Offset aus der Perspektive der VP verschieden sein, um beispielsweise Lücken in den GPA zu vermeiden. Man betrachte zum Beispiel ein Szenario, in dem jeder AFC eine 4K-Seite einnimmt, sodass der MMIO-Offset für AFC-0 0x0000 sein kann, wohingegen der MMIO-Offset für AFC-1 0x1000 ist. Falls der AFC-1 jedoch einer virtuellen Funktion zugewiesen ist, kann er dem MMIO-Offset 0x0000 zugeordnet sein, um zu vermeiden, dass sich im GPA-Raum aus Perspektive der VF Löcher öffnen. Während die Register 514 Lese-/Schreibzugriff aus der Perspektive der physischen Funktion (d. h. aus der Sicht der PF) aufweisen, weisen die Register 514 aus der Perspektive der virtuellen Funktionen (d. h. aus der Sicht der VF) nur Lesezugriff auf.
6 zeigt, wie die Vorrichtungsfunktionsliste 600 einer virtuellen Funktion im VF-Modus oder im gemischten Modus erscheint. Wie in 6 gezeigt, weist die virtuelle Funktion nur eine eingeschränkte Sicht eines PIC in Form eines virtuellen PIC auf, der auf einen entsprechenden AFC-DFH zeigt. Im Beispiel von 6 verwendet die virtuelle Funktion ihr MMIO-BAR, um einen virtuellen PIC-DFH (vPIC-DFH) zu identifizieren, der auf den AFC-0-DFH zeigt. Der mit dieser bestimmten VF assoziierte Hosttreiber kann in den AFC-0-DFH gehen, um die AFC-ID und Position von Register 516' in der Benutzerpartition zu erhalten, wie durch Pfad 650 angezeigt. Die Register 514', die mit dem AFC-0-DFH zum Speichern der AFC-ID, des MMIO-Offsets und der MMIO-Länge assoziiert sind, sind aus der Perspektive der VF schreibgeschützte Register. Das Beispiel von 6, in dem das VF-MMIO-BAR auf den AFC-0-DFH abgebildet ist, ist nur illustrativ. Im Allgemeinen kann das BAR jeder individuellen virtuellen Funktion in der in 5 gezeigten vollständigen Vorrichtungsfunktionsliste 500 auf einen jeweils anderen der AFC-DFHs abgebildet sein (z. B. kann eine zweite virtuelle Funktion auf den AFC-1-DFH abgebildet sein, eine dritte virtuelle Funktion kann auf den AFC-M-DFH abgebildet sein usw.) .
Im Beispiel von 6 sieht eine virtuelle Funktion nur einen entsprechenden AFC. Falls gewünscht, können der gleichen virtuellen Funktion mehrere AFCs dargelegt werden. Um dies zu erreichen, kann der PF-Treiber auch die DFH-Strukturen virtualisieren. Wenn beispielsweise eine oder mehrere der VF-MMIO-Seiten vom VMM nicht in (erweiterte) Seitentabellen auf zweiter Ebene abgebildet werden, werden alle Gast-Lese-/Schreibvorgänge in diese Seiten abgefangen und die Steuerung wird an die Softwarekomponente im Host-OS transferiert (z. B. den PF-Treiber oder ein virtuelles Vorrichtungszusammensetzungsmodul), um die benötigte DFL-/DFH-Ansicht zu emulieren. In noch einem weiteren Beispiel kann der PF-Treiber den Systemarbeitsspeicher zuweisen, den Systemarbeitsspeicher auf Grundlage der benötigten DFL-/DFH-Ansicht füllen und den Systemarbeitsspeicher mithilfe des VMM (z. B. über die erweiterten Seitentabellen auf zweiter Ebene) als die VF-MMIO darlegen.
7 ist ein Diagramm einer virtualisierten Vorrichtungsfunktionsliste (DFL) aus der Perspektive einer physischen Funktion im PF-Modus, im VF-Modus oder im gemischten Modus. Wie in 7 gezeigt, kann das PF-MMIO-BAR weiterhin auf einen PIC-DFH zeigen, der auf einen Anschluss-O-DFH zeigt. Die verschiedenen AFC-DFHs können jedoch unter Verwendung von virtualisierten PIC-DFHs (vPIC-DFHs) referenziert werden. Im Beispiel von 7 kann ein erster vPIC-DFH 702-1 mit dem AFC-0-DFH und dem AFC-X-DFH verknüpft sein, wohingegen ein zweiter vPIC-DFH 702-2 mit dem AFC-1-DFH, dem AFC-2-DFH und dem AFC-M-DFH verknüpft sein kann. Insbesondere können die AFC-DFHs, die mit einem bestimmten vPIC assoziiert sind, auf nicht sequenzielle programmierbare Register 516 in der AFU abbilden, wie durch Pfad 750 gezeigt. Diese Technik ermöglicht eine Umordnung von AFC-Blöcken auf eine beliebige gewünschte Weise, ohne Hardwareänderungen durchführen zu müssen, da die AFC-ID, der Offset und Längeninformationen programmierbar ist und über die Systemsoftware virtualisiert wird. Die mit der ersten virtualisierten PIC-Vorrichtung 702-1 assoziierten Register 514-1 und die mit der zweiten virtualisierten PIC-Vorrichtung 702-2 assoziierten Register 514-2 können auch im Systemarbeitsspeicher implementiert sein (siehe z. B. den CPU-Arbeitsspeicher 203 in 2). Die Verwendung des Systemarbeitsspeichers, um das DFL-/DFH-Layout zu erstellen, kann den Flächenverbrauch auf der Vorrichtung 100 reduzieren. Falls gewünscht kann das DFL-/DFH-Layout auch in einem privaten Vorrichtungsarbeitsspeicher, gestohlenen Arbeitsspeicher oder anderen Typen von externem Arbeitsspeicher implementiert werden. Falls gewünscht kann der AFU-DFH weiterhin als programmierbare Register im PIC 250 implementiert werden.
8 zeigt, wie die virtualisierte DFH-Struktur von 7 einer virtuellen Funktion im VF-Modus oder im gemischten Modus erscheint. Wie in 7 gezeigt, weist die virtuelle Funktion nur eine eingeschränkte Sicht eines PIC in Form eines virtuellen PIC auf, der auf einen oder mehrere entsprechende AFC-DFHs zeigt. Im Beispiel von 8 verwendet die virtuelle Funktion ihr MMIO-BAR, um einen virtuellen PIC-DFH (vPIC-DFH) 702-1 zu identifizieren, der auf den AFC-0-DFH und auf den AFC-X-DFH zeigt. Der mit dieser bestimmten VF assoziierte Hosttreiber kann in den AFC-0-DFH gehen, um die AFC-ID und Position des Registers 516-1 in der Benutzerpartition (wie durch Pfad 750-1 angezeigt) zu erhalten, und in den AFC-X-DFH, um die AFC-ID und Position des Registers 516-2 in der Benutzerpartition zu erhalten, wie durch Pfad 750-2 angezeigt. Die Register 514-1, die mit dem AFC-0- und dem AFC-X-DFH zum Speichern der AFC-ID, des MMIO-Offsets und der MMIO-Längeninformationen assoziiert sind, sind aus der Perspektive der VF schreibgeschützte Register. Eine ähnliche eingeschränkte Ansicht kann dem vPIC 702-2 bereitgestellt werden, der auf die nicht sequenziellen DFHs von AFC-1, AFC-Y und AFC-M abbildet. Andere virtuelle Funktionen (und BARs) zum Abbilden auf andere Teilmengen von AFCs können ebenfalls enthalten sein.
Die verschiedenen Vorrichtungsfunktionsköpfe (DFHs), die oben beschrieben sind, sind allgemein unter Verwendung programmierbarer DFH-Register auf der Vorrichtung 100 implementiert. Mit der Hinzufügung von context_id-Markierungen zur transaktionsübergreifenden Kommunikationsschnittstelle 254 müssen die DFH-Register diese Markierungen berücksichtigen. In einer geeigneten Anordnung können der PIC-DFH und optional der Anschluss-0-DFH (gemeinsam als der „AFU-DFH“ bezeichnet) als ein programmierbares Register im PIC 250 implementiert sein (siehe z. B. das DFH-Register 290 in 2), wohingegen die AFC-DFHs als DFH-Register implementiert sind, auf die über Anforderungen zugegriffen werden kann, die über die Schnittstelle 254 mit ihrer entsprechenden context_id markiert gesendet werden (siehe z. B. die DFH-Register 292 in 2).
In einer anderen geeigneten Anordnung ist der AFU-DFH innerhalb der AFU enthalten (siehe z. B. das AFU-DFH-Register 294 in 2) und ist über eine besondere Schnittstelle zugänglich. Diese besondere Schnittstelle kann eine unabhängige Schnittstelle, eine Sondertransaktion oder auf eine besondere context_id-Markierung wie 0 oder -1 abgebildet sein. Die AFC-DFHs können wiederum als Register 292 innerhalb jedes AFC implementiert sein und sind über Anforderungen zugänglich, die durch die Schnittstelle 254 mit ihrer entsprechenden context_id-Markierung markiert gesendet werden.
In noch einer anderen geeigneten Anordnung können der AFU-DFH und die AFC-DFHs alle als programmierbare Register im PIC 250 implementiert sein. In dieser Konfiguration können die DFH-Register parallel zusammen mit der teilweisen Neukonfiguration jeder AFU aktualisiert werden. 9 ist ein Ablaufdiagramm von illustrativen Schritten zum Neukonfigurieren einer AFU. Bei Schritt 900 kann eine programmierbare Vorrichtung 100 einen Bitstrom zur teilweisen AFU-Neukonfiguration und assoziierte AFU-Metadaten empfangen. Bei Schritt 902 kann die Vorrichtung 100 die teilweise AFU-Neukonfigurationsfunktion initiieren, um den neu empfangenen AFU-Bitstrom in den entsprechenden PR-Schlitz zu laden.
Bei Schritt 904 wird mindestens eine AFU unter Verwendung des AFU-Bitstroms neu konfiguriert. Nach Aktualisieren der AFU können die entsprechenden DFH-Register im PIC 250 unter Verwendung der empfangenen AFU-Metadaten aktualisiert werden (um z. B. DFH-Register mit neuen AFU- und AFC-IDs, mit einem neuen AFU-Leistungsbudget oder mit anderen Steuereinstellungen zu aktualisieren). Bei Schritt 908 kann der PIC 250 die Kontextabbildungstabelle einrichten, um die neuen AFU-/AFC-Einstellungen aufzunehmen (um z. B. optional bei Bedarf die context_id zu aktualisieren). Nach dem Aktualisieren der Kontextabbildungstabelle kann die AFU-Neuprogrammierung abgeschlossen sein (bei Schritt 910).
Im Allgemeinen können die AFU-/AFC-Kennung und Positionsinformationen, die Kontextabbildungstabellen und andere assoziierte Parameter auf Kontextebene von der physischen Funktion während teilweiser Neukonfigurationsvorgängen oder während eines VF-Zuweisungs-/Entfernungsprozesses aktualisiert werden. 10A ist ein Ablaufdiagramm von illustrativen Schritten zum Zuweisen einer virtuellen Funktion zu einem bestimmten AFC. Bei Schritt 1000 kann eine virtuelle Funktion wie VFx als eine virtuelle Funktion identifiziert werden, die aktuell für eine neue Zuordnung verfügbar ist.
Bei Schritt 1002 kann ein AFC, der einer virtuellen Funktion zugewiesen werden muss, identifiziert werden. Bei Schritt 1004 kann der identifizierte AFC stillgelegt werden. Bei Schritt 1006 kann eine Rücksetzung auf Kontextebene (siehe 4) an den identifizierten AFC ausgegeben werden.
Bei Schritt 1008 können die Kontextabbildungstabelle 260-1 (3A), die Umkehrkontextabbildungstabelle 260-2 (3B) und optional der MMIO-Decoder 264 (2) aktualisiert werden, um die BDF-Nummer der VFx anstatt der BDF-Nummer der PF einzusetzen. Im Fall von skalierbarer IOV kann die BDF-Nummer gleich gelassen werden, während nur die PASID aktualisiert wird.
Bei Schritt 1010 kann die Position des AFC aus der Perspektive der PF in Treiberstrukturen (d. h. in Software) gespeichert werden und der tatsächliche DFH kann aktualisiert werden, um die Ansicht der VF zu reflektieren. Bei Schritt 1012 kann die VFx dann einer virtuellen Maschine oder einem Container zugewiesen werden. Im Allgemeinen können die Schritte von 10A unter Verwendung des PIC 250 oder einer anderen Steuereinheit innerhalb des Systems durchgeführt werden.
10B ist ein Ablaufdiagramm von illustrativen Schritten zum Entfernen einer virtuellen Funktion von einem AFC. Bei Schritt 1050 kann eine virtuelle Funktion wie VFy als eine virtuelle Funktion identifiziert werden, die entfernt oder deren Zuweisung zu einem AFC aufgehoben werden muss.
Bei Schritt 1052 kann ein entsprechender AFC, der mit VFy assoziiert ist, identifiziert werden. Bei Schritt 1054 kann der identifizierte AFC stillgelegt werden. Bei Schritt 1056 kann VFy von der virtuellen Maschine oder vom Container entfernt werden, auf der bzw. dem sie aktuell residiert.
Bei Schritt 1058 kann eine Rücksetzung auf Kontextebene (siehe 4) an den identifizierten AFC ausgegeben werden. Bei Schritt 1060 können die Kontextabbildungstabelle 260-1 (3A), die Umkehrkontextabbildungstabelle 260-2 (3B) und optional der MMIO-Decoder 264 (2) aktualisiert werden, um die BDF-Nummer der PF anstatt der BDF-Nummer der VFy einzusetzen. Im Fall von skalierbarer IOV kann die BDF-Nummer gleich gelassen werden, während nur die PASID aktualisiert wird.
Bei Schritt 1062 kann dann die Position des AFC aus der Perspektive der PF wiederhergestellt werden. Im Allgemeinen können die Schritte von 10A unter Verwendung des PIC 250 oder einer anderen Steuereinheit innerhalb des Systems durchgeführt werden.
Die Ausführungsformen wurden bisher in Bezug auf integrierte Schaltkreise beschrieben. Die hierin beschriebenen Verfahren und Einrichtungen können in einen beliebigen geeigneten Schaltkreis eingebunden werden. Sie können zum Beispiel in zahlreiche Arten von Vorrichtungen wie programmierbare Logikvorrichtungen, anwendungsspezifische Standardprodukte (ASSPs) und anwendungsspezifische integrierte Schaltkreise (ASICs), Mikrocontroller, Mikroprozessoren, Zentralverarbeitungseinheiten (CPUs), Grafikverarbeitungseinheiten (GPUs) usw. eingebunden werden. Beispiele programmierbarer Logikvorrichtungen enthalten programmierbare Anordnungslogik (PALs), programmierbare Logikanordnungen (PLAs), feldprogrammierbare Logikanordnungen (FPLAs), elektrisch programmierbare Logikvorrichtungen (EPLDs), elektrisch löschbare programmierbare Logikvorrichtungen (EEPLDs), Logikzellenanordnungen (LCAs), komplexe programmierbare Logikvorrichtungen (CPLDs) und feldprogrammierbare Gatearrays (FPGAs), um nur einige zu nennen.
Die in einer oder mehreren Ausführungsformen hierin beschriebene programmierbare Logikvorrichtung kann ein Teil eines Datenverarbeitungssystems sein, das eine oder mehrere der folgenden Komponenten enthält: einen Prozessor; Arbeitsspeicher; EA-Verschaltung; und periphere Vorrichtungen. Die Datenverarbeitung kann in einer breiten Vielfalt von Anwendungen verwendet werden, wie Computervernetzung, Datenvernetzung, Instrumentierung, Videoverarbeitung, digitaler Signalverarbeitung oder einer beliebigen andere geeigneten Anwendung, wo der Vorteil der Verwendung von programmierbarer oder neu programmierbarer Logik wünschenswert ist. Die programmierbare Logikvorrichtung kann verwendet werden, um eine Vielfalt von verschiedenen Logikfunktionen durchzuführen. Die programmierbare Logikvorrichtung kann zum Beispiel als ein Prozessor oder eine Steuerung konfiguriert sein, die in Zusammenarbeit mit einem Systemprozessor arbeitet. Die programmierbare Logikvorrichtung kann auch als ein Arbiter zum Vermitteln von Zugriff auf eine gemeinsam genutzte Ressource im Datenverarbeitungssystem verwendet werden. In noch einem anderen Beispiel kann die programmierbare Logikvorrichtung als eine Schnittstelle zwischen einem Prozessor und einer der anderen Komponenten im System ausgelegt sein.
Das Vorstehende ist lediglich veranschaulichend für die Prinzipien dieser Erfindung und verschiedene Modifikationen können von Fachleuten vorgenommen werden. Die vorstehenden Ausführungsformen können einzeln oder in beliebiger Kombination implementiert werden.

Claims

System, umfassend: einen Hostprozessor, der betriebsfähig ist, um Aufgaben auszulagern; und einen Coprozessor, der über eine Hostschnittstelle an den Hostprozessor gekoppelt ist, wobei der Coprozessor betriebsfähig ist, die ausgelagerten Aufgaben zu empfangen und dem Hostprozessor eine Hardwarebeschleunigung bereitzustellen, und wobei der Coprozessor umfasst: einen Bereich für teilweise Neukonfiguration, in den eine Beschleunigerfunktionseinheit (AFU) geladen ist, wobei die AFU in eine Vielzahl von Beschleunigerfunktionseinheitskontexten (AFCs) unterteilt ist; und einen Schnittstellenschaltkreis, der betriebsfähig ist, um mindestens eine der Vielzahl von AFCs auf eine entsprechende, durch den Host zuweisbare Schnittstelle abzubilden, die zumindest teilweise die Hostschnittstelle zwischen dem Hostprozessor und dem Coprozessor umspannt.
System nach Anspruch 1, wobei die Hostschnittstelle eine aus einer Peripheral-Component-Interconnect-Express(PCIe)-Schnittstelle, einer Cache-Coherent-Interconnect-for-Accelerators(CCIX)-Schnittstelle, einer Gen-Z-Schnittstelle, einer Open-Coherent-Accelerator-Processor-Interface(OpenCAPI)-Schnittstelle, einer Intel-Accelerator-Link(IAL)-Schnittstelle und einer NVLink-Schnittstelle ausgewählte ist.
System nach Anspruch 1, wobei die Hostschnittstelle eine Peripheral-Component-Interconnect-Express(PCIe)-Schnittstelle ist, die eine Einzel-Root-Eingabe/Ausgabe-Virtualisierung (SR-IOV) oder eine skalierbare Eingabe/Ausgabe-Virtualisierung (skalierbare IOV) unterstützt.
System nach Anspruch 3, wobei die durch den Host zuweisbare Schnittstelle eine aus einer physischen PCIe-Funktion, einer virtuellen PCIe-SR-IOV-Funktion und einer zuweisbaren skalierbaren PCIe-IOV-Vorrichtungsschnittstelle ausgewählte ist.
System nach einem der Ansprüche 1-4, wobei die durch den Host zuweisbare Schnittstelle mit einem Aufgabenauslagerungsmodul assoziiert ist, ausgewählt aus der Gruppe bestehend aus: einer virtuellen Maschine auf dem Hostprozessor, einem Container auf dem Hostprozessor und einem Prozess auf dem Hostprozessor.
System nach einem der Ansprüche 1-5, wobei die Vielzahl von AFCs mit eindeutigen Kontextkennungen versehen ist und wobei Transaktionen zwischen dem Schnittstellenschaltkreis und der AFU mit den eindeutigen Kontextkennungen markiert sind, um eine Adressraumisolierung bereitzustellen.
System nach Anspruch 6, wobei der Schnittstellenschaltkreis eine Kontextabbildungstabelle verwendet, um die eindeutigen Kontextkennungen auf plattformspezifische Kennungen für vorgeschaltete und nachgeschaltete Arbeitsspeicheranforderungen zwischen dem Hostprozessor und der Vielzahl von AFCs und für vom Hostprozessor initiierte Anforderungen an die Vielzahl von AFCs abzubilden.
System nach Anspruch 7, wobei die plattformspezifischen Kennungen Peripheral-Component-Interconnect-Express(PCIe)-Bus-, Vorrichtungs- und Funktionsnummern und optional eine Prozess-Adressraum-Kennung (PASID) umfassen.
System nach Anspruch 8, wobei: die durch den Host zuweisbare Schnittstelle eine physische PCIe-Funktion umfasst und alle der AFCs in der AFU mit der physischen PCIe-Funktion assoziiert sind und auf alle der AFCs in der AFU durch die physische PCIe-Funktion während eines physischen Funktionsmodus (PF-Modus) zugegriffen wird; die durch den Host zuweisbare Schnittstelle eine virtuelle PCIe-Funktion umfasst und alle der AFCs in der AFU mit der virtuellen PCIe-Funktion assoziiert sind und auf alle der AFCs in der AFU durch die physische PCIe-Funktion während eines virtuellen Funktionsmodus (VF-Modus) zugegriffen wird; oder mindestens ein erster Abschnitt der AFCs in der AFU mit der physischen PCIe-Funktion assoziiert ist und auf den mindestens einen ersten Abschnitt der AFCs in der AFU über die physische PCIe-Funktion zugegriffen wird, und wobei während eines gemischten Modus mindestens ein zweiter Abschnitt der AFCs in der AFU mit der virtuellen PCIe-Funktion assoziiert ist und auf den mindestens einen zweiten Abschnitt der AFCs in der AFU über die virtuelle PCIe-Funktion zugegriffen wird.
System nach Anspruch 9, wobei der Schnittstellenschaltkreis ferner eine interne Tabelle zum Speichern der eindeutigen Kontextkennungen umfasst und wobei die interne Tabelle durch PCIe-Markierungen indiziert ist, die automatisch mit den vorgeschalteten Arbeitsspeicheranforderungen assoziiert sind und mit den nachgeschalteten Arbeitsspeicheranforderungen zurückgegeben werden.
System nach Anspruch 9, wobei der Coprozessor ferner einen Adressendecodierer.umfasst, der ausgelegt ist, die eindeutigen Kontextkennungen auf Grundlage einer im Arbeitsspeicher abgebildeten Eingabe-Ausgabe-Adresse (MMIO-Adresse) zu decodieren, die mit der durch den Host zuweisbaren Schnittstelle assoziiert ist.
System nach einem der Ansprüche 1-11, wobei ein bestimmter AFC in der Vielzahl von AFCs betriebsfähig ist, um eine Unterbrechung an den Hostprozessor auszugeben, und wobei die Unterbrechung mit einer eindeutigen Kontextkennung markiert ist, die nur mit dem bestimmten AFC assoziiert ist.
System nach einem der Ansprüche 1-12, wobei der Coprozessor eine Vorrichtungsfunktionsliste pflegt, die dem Hostprozessor ermöglicht, die Vielzahl von AFCs zu nummerieren, wobei der Schnittstellenschaltkreis von der durch den Host zuweisbaren Schnittstelle verwaltet wird und wobei die durch den Host zuweisbare Schnittstelle ein Basisadressenregister aufweist, das auf die Vorrichtungsfunktionsliste zeigt, wobei die Vorrichtungsfunktionsliste eine verknüpfte Liste mit Vorrichtungsfunktionsköpfen umfasst, wobei ein erster der Vorrichtungsfunktionsköpfe Kennungs- und Positionsinformationen freigibt, die mit der AFU assoziiert sind, und wobei eine Reihe der Vorrichtungsfunktionsköpfe Kennungs- und Positionsinformationen freigibt, die mit der Vielzahl von AFCs assoziiert sind.
System nach Anspruch 13, wobei die Kennungs- und Positionsinformationen, die mit der AFU und der Vielzahl von AFCs assoziiert sind, in programmierbaren Registern innerhalb des Schnittstellenschaltkreises gespeichert sind.
System nach Anspruch 13, ferner umfassend einen externen Arbeitsspeicher, der an den Hostprozessor gekoppelt ist, wobei die Kennungs- und Positionsinformationen, die mit der AFU und der Vielzahl von AFCs assoziiert sind, im externen Arbeitsspeicher gespeichert sind.
System nach Anspruch 13, ferner umfassend einen Arbeitsspeicher, der an den Hostprozessor gekoppelt ist, wobei die Kennungs- und Positionsinformationen, die mit der AFU assoziiert sind, in programmierbaren Registern innerhalb des Schnittstellenschaltkreises gespeichert sind, und wobei die Kennungs- und Positionsinformationen, die mit der Vielzahl von AFCs assoziiert sind, im Arbeitsspeicher gespeichert sind.
System nach Anspruch 13, wobei die Vorrichtungsfunktionsköpfe als programmierbare Register innerhalb des Schnittstellenschaltkreises implementiert sind, wobei die durch den Host zuweisbare Schnittstelle eine privilegierte, durch den Host zuweisbare Schnittstelle umfasst und wobei die programmierbaren Register unter Verwendung der privilegierten, durch den Host zuweisbaren Schnittstelle programmiert sind.
System nach Anspruch 13, wobei zumindest einige der Vorrichtungsmerkmalsköpfe als programmierbare Register innerhalb des Bereichs für teilweise Neukonfiguration der AFU implementiert sind.
System nach Anspruch 13, wobei die durch den Host zuweisbare Schnittstelle eine privilegierte, durch den Host zuweisbare Schnittstelle umfasst und wobei auf jeden Vorrichtungsmerkmalskopf in der Reihe von Vorrichtungsmerkmalsköpfen unter Verwendung des Basisadressenregisters der privilegierten, durch den Host zuweisbaren Schnittstelle zugegriffen werden kann.
System nach Anspruch 13, wobei die durch den Host zuweisbare Schnittstelle eine nicht privilegierte, durch den Host zuweisbare Schnittstelle umfasst und wobei nur auf eine Teilmenge der Vorrichtungsmerkmalsköpfe in der Reihe von Vorrichtungsmerkmalsköpfen unter Verwendung eines Basisadressenregisters zugegriffen werden kann, das mit der nicht privilegierten, durch den Host zuweisbaren Schnittstelle assoziiert ist.
System nach Anspruch 13, wobei die durch den Host zuweisbare Schnittstelle eine privilegierte, durch den Host zuweisbare Schnittstelle umfasst, die betriebsfähig ist, um die Vorrichtungsfunktionsliste oder zumindest einige der Vorrichtungsfunktionsköpfe in der Vorrichtungsfunktionsliste neu zu programmieren.
Verfahren zum Betreiben eines Systems, das einen Hostprozessor und eine programmierbare Beschleunigervorrichtung enthält, wobei das Verfahren umfasst: Auslagern von Aufgaben vom Hostprozessor an die programmierbare Beschleunigervorrichtung; Konfigurieren eines Schlitzes in der programmierbaren Beschleunigervorrichtung, um eine Beschleunigerfunktionseinheit (AFU) zu implementieren, wobei die AFU in eine Vielzahl von Beschleunigerfunktionseinheitskontexten (AFCs) unterteilt ist; und Verwenden eines Schnittstellenschaltkreises in der programmierbaren Beschleunigervorrichtung, um die Vielzahl von AFCs auf entsprechende, durch den Host zuweisbare Schnittstellen abzubilden und um einen Rücksetzvorgang auf Kontextebene an einem ausgewählten AFC in der Vielzahl von AFCs durchzuführen.
Verfahren nach Anspruch 22, wobei der Rücksetzvorgang auf Kontextebene über ein auf die AFU gerichtetes Rücksetzen auf Funktionsebene oder über mit dem Schnittstellenschaltkreis assoziierte Verwaltungsregister initiiert wird, wobei das Verfahren ferner umfasst: Verwenden des Schnittstellenschaltkreises, um auf den ausgewählten AFC abgezielte Transaktionen zu filtern; Verwenden des Schnittstellenschaltkreises, um eine Rücksetznachricht auf Kontextebene (CLR-Nachricht) an den ausgewählten AFC zu senden, um die AFU anzuweisen, aufzuhören, mit dem ausgewählten AFC assoziierte Anforderungen auszugeben; als Reaktion auf das Empfangen der CLR-Nachricht vom Schnittstellenschaltkreis, Verwenden des ausgewählten AFC, um eine Rücksetzbestätigung auf Kontextebene (CLR-Bestätigung) an den Schnittstellenschaltkreis zurückzugeben; nach Senden der CLR-Nachricht an den ausgewählten AFC, Warten, bis alle anstehenden vorgeschalteten und nachgeschalteten Anforderungen geleert sind, die mit dem ausgewählten AFC assoziiert sind, bevor der Rücksetzvorgang auf Funktionsebene für den ausgewählten AFC beendet wird; und Verwenden des ausgewählten AFC, um eine neue Rücksetznachricht auf Kontextebene (CLR-Nachricht) an einen anderen AFC in der Vielzahl von AFCs zu senden.
Verfahren zum Betreiben eines Systems, das eine Host-Zentralverarbeitungseinheit (CPU) und eine assoziierte Beschleunigungsvorrichtung enthält, wobei das Verfahren umfasst: Auslagern von Aufgaben von der Host-CPU an die Beschleunigungsvorrichtung; und teilweises Neukonfigurieren eines Schlitzes in der Beschleunigungsvorrichtung, um eine Beschleunigerfunktionseinheit (AFU) zu implementieren, wobei die AFU in eine Vielzahl von Beschleunigerfunktionseinheitskontexten (AFCs) unterteilt ist, die entsprechende, durch den Host zuweisbare Schnittstellen abbilden.
Verfahren nach Anspruch 24, ferner umfassend: Aktualisieren von Vorrichtungsfunktionskopfregistern in der Beschleunigungsvorrichtung mit neuen Kennungsinformationen, die mit der AFU und den AFCs assoziiert sind; und Einrichten einer Kontextabbildungstabelle, um die neuen Kennungsinformationen aufzunehmen, wobei die Kontextabbildungstabelle eindeutige Kontextkennungen, die mit der Vielzahl von AFCs assoziiert sind, auf plattformspezifische Kennungen abbildet.