DXGKDDI_BUILDPAGINGBUFFER Rückruffunktion (d3dkmddi.h)

Artikel
02/23/2024

Die DxgkDdiBuildPagingBuffer-Funktion erstellt Pagingpuffer für Speichervorgänge.

Syntax

DXGKDDI_BUILDPAGINGBUFFER DxgkddiBuildpagingbuffer;

NTSTATUS DxgkddiBuildpagingbuffer(
  [in]     IN_CONST_HANDLE hAdapter,
  [in/out] IN_PDXGKARG_BUILDPAGINGBUFFER pBuildPagingBuffer
)
{...}

Parameter

[in] hAdapter

Ein Handle für einen Kontextblock, der einer Grafikkarte zugeordnet ist. Der Anzeige-Miniporttreiber hat dieses Handle zuvor für das Microsoft DirectX-Grafikkernsubsystem im Ausgabeparameter MiniportDeviceContext der DxgkDdiAddDevice-Funktion bereitgestellt.

[in/out] pBuildPagingBuffer

Ein Zeiger auf eine DXGKARG_BUILDPAGINGBUFFER-Struktur , die Informationen zum Erstellen eines Pagingpuffers enthält.

Rückgabewert

DxgkDdiBuildPagingBuffer gibt einen der folgenden Werte zurück:

Rückgabecode	Beschreibung
STATUS_SUCCESS	DxgkDdiBuildPagingBuffersuccessfully hat einen Pagingpuffer erstellt.
STATUS_GRAPHICS_ALLOCATION_BUSY	Die GPU verwendet derzeit die Zuordnung für den Pagingpuffer.
STATUS_GRAPHICS_INSUFFICIENT_DMA_BUFFER	Im Pagingpuffer ist mehr Speicherplatz erforderlich (d. a. im pDmaBuffer-Element der DXGKARG_BUILDPAGINGBUFFER-Struktur , auf die der pBuildPagingBuffer-Parameter verweist).

Hinweise

Die DxgkDdiBuildPagingBuffer-Funktion wird aufgerufen, um spezielle DMA-Puffer (Direct Memory Access) zu erstellen, die als Pagingpuffer bezeichnet werden. Ein Auslagerungspuffer enthält einen Vorgang, der den Inhalt von Teilen von Zuordnungen verschiebt:

Innerhalb eines Segments einer Zuordnung.
Zwischen Segmenten von Zuordnungen.
Aus einem Segment einer Zuordnung zum Systemspeicher.
Vom Systemspeicher in ein Segment einer Zuordnung.

Der Display-Miniporttreiber muss die entsprechende GPU-Anweisung (Graphics Processing Unit) gemäß dem angeforderten Pagingvorgang in den bereitgestellten Pagingpuffer (im pDmaBuffer-Element von DXGKARG_BUILDPAGINGBUFFER) schreiben. und dann muss der Treiber den Auslagerungspuffer an den Videospeicher-Manager zurückgeben (der Teil von Dxgkrnl.sysist). Der GPU-Scheduler (der auch Teil von Dxgkrnl.sysist) ruft anschließend die DxgkDdiSubmitCommand-Funktion des Treibers auf, um anzufordern, dass der Treiber den Pagingpuffer als regulären DMA-Puffer an die GPU übermittelt.

Hinweis Bevor der Videospeicher-Manager den Pagingpuffer übermittelt, ruft er die DxgkDdiPatch-Funktion des Treibers auf, um dem Pagingpuffer physische Adressen (d. h. Patch) zuzuweisen. Im Aufruf von DxgkDdiPatch stellt der Videospeicher-Manager jedoch keine Patchspeicherortlisten bereit. Die DxgkDdiPatch-Funktion des Treibers kann in letzter Minute Aktualisierungen des Pagingpuffers durchführen. Die DxgkDdiPatch-Funktion des Treibers kann jedoch die Größe des Pagingpuffers nicht ändern.

Wenn der Treiber den Pagingpuffer erfolgreich erstellt, sollte der DxgkDdiBuildPagingBuffer des Treibers pDmaBuffer aktualisieren, um über das letzte Byte zu verweisen, das in den Pagingpuffer geschrieben wurde, und dann STATUS_SUCCESS zurückgeben. Da DxgkDdiBuildPagingBuffer nur dann fehlschlagen kann, wenn im Pagingpuffer nicht genügend Speicherplatz vorhanden ist, sollte der Treiber immer überprüfen, ob der Auslagerungspuffer über genügend Speicherplatz verfügt, bevor er in den Puffer schreibt. Wenn nicht genügend Speicherplatz im Pagingpuffer verbleibt, sollte der Treiber STATUS_GRAPHICS_INSUFFICIENT_DMA_BUFFER zurückgeben. Der Videospeicher-Manager ruft dann einen neuen Pagingpuffer ab und ruft die DxgkDdiBuildPagingBuffer-Funktion des Treibers erneut auf, um den neuen Pagingpuffer entsprechend dem angeforderten Pagingvorgang aufzufüllen. Beachten Sie, dass für einen bestimmten angeforderten Pagingvorgang, der mehrere Pagingpuffer auffüllt, der Planer die DxgkDdiSubmitCommand-Funktion des Treibers mehrmals aufruft, damit jeder Partielle Pagingpuffer unabhängig übermittelt wird.

Wenn DxgkDdiBuildPagingBuffer feststellt, dass ein Pagingvorgang mehr als einen Pagingpuffer erfordert, kann der Treiber Informationen im MultipassOffset-Element von DXGKARG_BUILDPAGINGBUFFER angeben und diese Informationen über mehrere Iterationen des Pagingvorgangs hinweg verwenden. Der Videospeicher-Manager initialisiert die Informationen in MultipassOffset vor der ersten Anforderung des Auslagerungsvorgangs auf Null und ändert die Informationen in MultipassOffset zwischen Iterationen nicht. Daher kann der Treiber MultipassOffset verwenden, um den Fortschritt zwischen Iterationen zu speichern. Beispielsweise kann der Treiber die Seitenzahl speichern, die zuletzt für eine seitenbasierte Übertragung übertragen wurde.

Ein Pagingpuffer wird derzeit für die folgenden Arten von Vorgängen erstellt:

Übertragen
Der Übertragungsvorgang verschiebt den Inhalt einer Zuordnung von einem Standort an einen anderen. Dieser Vorgang ist die am häufigsten verwendete Art von Speichervorgang.

Eine Zuordnung wird immer vollständig von einem Standort zum anderen übertragen. Aufgrund von Speichereinschränkungen kann die Übertragung einer Zuordnung jedoch in mehrere Teilübertragungen unterteilt werden (d. a. ein Teil der Zuordnung wird von Standort A nach B verschoben, und dann wird der folgende Teil verschoben usw., bis die gesamte Zuordnung übertragen wird). Die erste Teilübertragung einer Zuordnung wird mit dem TransferStart-Bitfeldflag im Flags-Member des Transfer-Elements von DXGKARG_BUILDPAGINGBUFFER gekennzeichnet. Die letzte Teilübertragung einer Zuordnung wird mit dem Bitfeldflag TransferEnd gekennzeichnet. Der Treiber erhält garantiert das Ende einer ausstehenden Übertragung (d. h. der letzten Teilübertragung), bevor der Fahrer den Beginn einer neuen Übertragung erhält.

Für jede Teilübertragung sind möglicherweise mehrere Aufrufe von DxgkDdiBuildPagingBuffer erforderlich (z. B. kann der DMA-Pufferspeicher für den Treiber nicht mehr vorhanden sein). Daher kann der Treiber das TransferStart-Flag in mehreren Aufrufen von DxgkDdiBuildPagingBuffer erhalten, bis der Treiber das TransferEnd-Flag in einem Aufruf von DxgkDdiBuildPagingBuffer empfängt. Das mehrfache Empfangen des TransferStart-Flags bedeutet nicht, dass mehrere neue Übertragungen gestartet werden. Es gibt an, dass die Teilübertragungen für die Zuordnung mehrere Iterationen erfordern (z. B. wenn dem Treiber der DMA-Pufferspeicher nicht mehr ausreicht). Der Treiber kann den MultipassOffset-Member von DXGKARG_BUILDPAGINGBUFFER verwenden, um den Fortschritt für eine bestimmte Teilübertragung über mehrere Iterationen von DxgkDdiBuildPagingBuffer hinweg nachzuverfolgen.

In der Regel erfolgt eine Übertragung in einem einzelnen Vorgang. In diesem Fall werden die Bitfeldflags TransferStart und TransferEnd festgelegt.

In einigen Szenarien kann der Treiber zum Einrichten von Hardwareressourcen erforderlich sein, wenn bestimmte Zuordnungen in oder außerhalb des Arbeitsspeichers ausgelagert werden. Standardmäßig verwendet die GPU möglicherweise die Zuordnung, auf die während des Aufrufs von DxgkDdiBuildPagingBuffer verwiesen wird. In diesen Szenarien kann es für den Treiber erforderlich sein, dass sich die Zuordnung im Leerlauf befindet, bevor der Treiber die erforderlichen Hardwareressourcen programmiert (das heißt, die Programmierung der Hardwareressourcen kann nicht im bereitgestellten DMA-Puffer in die Warteschlange eingereiht werden). In solchen Szenarien kann der Treiber den Aufruf von DxgkDdiBuildPagingBuffer mit STATUS_GRAPHICS_ALLOCATION_BUSY fehlschlagen.

Wenn der Treiber STATUS_GRAPHICS_ALLOCATION_BUSY zurückgibt, wartet der Videospeicher-Manager, bis die GPU mit einem Verweis auf die aktuelle Zuordnung fertig ist, und ruft dann die DxgkDdiBuildPagingBuffer-Funktion des Treibers erneut auf. Beim zweiten Aufruf von DxgkDdiBuildPagingBuffer legt der Videospeicher-Manager das Bitfeldflag AllocationIsIdle im Flags-Member des Transfer-Elements von DXGKARG_BUILDPAGINGBUFFER fest, um anzugeben, dass die Zuordnung, auf die verwiesen wird, im Leerlauf liegt. Wenn das Leerlaufflag nicht festgelegt ist, sollte der Treiber immer feststellen, dass die Zuordnung entweder aktuell ausgelastet ist oder bald ausgelastet ist. Wenn das Idle-Flag festgelegt ist, garantiert der Videospeicher-Manager, dass die Zuordnung, auf die verwiesen wird, für die Dauer des Aufrufs von DxgkDdiBuildPagingBuffer im Leerlauf verbleibt.

Wenn der hAllocation-Member von DXGKARG_BUILDPAGINGBUFFER NULL ist, sollte der Treiber die Daten in der Quelle an das Ziel kopieren, ohne ein Schwenken oder Kacheln durchzuführen.
Füllung
Der Füllvorgang füllt eine Zuordnung mit einem angegebenen Muster aus. Der Füllvorgang wird verwendet, um den anfänglichen Inhalt einer Zuordnung einzurichten. Wenn der Inhalt der Zuordnung gefüllt ist, ist die Zuordnung garantiert im Leerlauf (d. a. wird nicht von der GPU verwendet). Der Füllvorgang kann nur für ein Speichersegment ausgeführt werden. Der Videospeicher-Manager fordert niemals an, dass der Anzeige-Miniporttreiber ein Blendensegment ausfüllt.
Verwerfen von Inhalten
Der Vorgang discard-content benachrichtigt den Treiber, dass eine Zuordnung vom aktuellen Speicherort der Zuordnung in einem Speichersegment verworfen wird. Das heißt, die Zuordnung wird entfernt und nicht zurück in den Systemspeicher kopiert.

In einigen Szenarien kann der Treiber zum Einrichten von Hardwareressourcen erforderlich sein, wenn bestimmte Zuordnungen in oder außerhalb des Arbeitsspeichers ausgelagert werden. Standardmäßig verwendet die GPU möglicherweise die Zuordnung, auf die beim Aufruf von DxgkDdiBuildPagingBuffer verwiesen wird. In diesen Szenarien kann es für den Treiber erforderlich sein, dass sich die Zuordnung im Leerlauf befindet, bevor der Treiber die erforderlichen Hardwareressourcen programmiert (das heißt, die Programmierung der Hardwareressourcen kann nicht im bereitgestellten DMA-Puffer in die Warteschlange eingereiht werden). In solchen Szenarien kann der Treiber den Aufruf von DxgkDdiBuildPagingBuffer mit STATUS_GRAPHICS_ALLOCATION_BUSY fehlschlagen.

Wenn der Treiber STATUS_GRAPHICS_ALLOCATION_BUSY zurückgibt, wartet der Videospeicher-Manager, bis die GPU mit einem Verweis auf die aktuelle Zuordnung fertig ist, und ruft dann die DxgkDdiBuildPagingBuffer-Funktion des Treibers erneut auf. Beim zweiten Aufruf von DxgkDdiBuildPagingBuffer legt der Videospeicher-Manager das Bitfeldflag AllocationIsIdle im Flags-Element des DiscardContent-Elements der DXGKARG_BUILDPAGINGBUFFER-Struktur fest, um anzugeben, dass die Zuordnung, auf die verwiesen wird, im Leerlauf liegt. Wenn das Leerlaufflag nicht festgelegt ist, sollte der Treiber immer feststellen, dass die Zuordnung entweder aktuell ausgelastet ist oder bald ausgelastet ist. Wenn das Idle-Flag festgelegt ist, garantiert der Videospeicher-Manager, dass die Zuordnung, auf die verwiesen wird, für die Dauer des Aufrufs von DxgkDdiBuildPagingBuffer im Leerlauf verbleibt.
Physisches Lesen
Der schreibphysische Vorgang liest aus einer angegebenen physischen Speicheradresse. Der Treiber wird angefordert, um die GPU für den Vorgang zu programmieren. Die Größe des physischen Arbeitsspeichers, auf den für den Lesevorgang zugegriffen werden soll, kann zwischen 1 byte und 8 Bytes betragen. Da die gelesenen Daten irrelevant sind, ist DxgkDdiBuildPagingBuffer nicht erforderlich, um die Daten zurückzugeben. In Szenarien, in denen die CPU jedoch versucht, aus dem AGP-Arbeitsspeicher zu lesen, nachdem die GPU in diesen AGP-Speicher geschrieben hat, ist der schreibphysische Vorgang von entscheidender Bedeutung, um die Speicherkohärenz sicherzustellen.
Physisches Schreiben
Der schreib-physische Vorgang schreibt in eine angegebene physische Adresse. Der Treiber wird angefordert, um die GPU für den Vorgang zu programmieren. Die Größe des physischen Arbeitsspeichers, auf den für den Schreibvorgang zugegriffen werden soll, kann zwischen 1 byte und 8 Byte betragen. Da die geschriebenen Daten irrelevant sind, kann DxgkDdiBuildPagingBuffer beliebige Daten in den Arbeitsspeicher schreiben. In Szenarien, in denen die CPU jedoch versucht, aus dem AGP-Arbeitsspeicher zu lesen, nachdem die GPU in diesen AGP-Arbeitsspeicher geschrieben hat, ist der Schreib-physischer Vorgang entscheidend, um die Arbeitsspeicherkohärenz sicherzustellen.
Kartenöffnungssegment
Der Vorgang map-aperture-segment ordnet eine angegebene Speicherdeskriptorliste (Memory Descriptor List, MDL) einem angegebenen Blendensegment an einem angegebenen Segmentoffset für eine angegebene Anzahl von Seiten zu. Wenn das CacheCoherent-Bitfeldflag im Flags-Member des MapApertureSegment-Elements der DXGKARG_BUILDPAGINGBUFFER-Struktur festgelegt ist, muss der Treiber sicherstellen, dass die Cachekohärenz auf den zugeordneten Seiten erzwungen wird. Andernfalls ist für die zugeordneten Seiten keine Cachekohärenz erforderlich.

Hinweis Das CacheCoherent-Bitfeldflag wird nur festgelegt, wenn zwischenspeicherbarer Speicher einem cache-kohärenten Blendensegment zugeordnet wird, und niemals auf ein nicht cache-kohärentes Blendensegment oder auf eine kombinierte Schreibzuordnung festgelegt wird, die einem zwischengespeicherten Segment zugeordnet wird.

Der Treiber kann optional memory-mapped I/O (MMIO) verwenden, um ein Blendensegment zu konfigurieren. Die GPU greift zur Konfigurationszeit nicht auf den Blendenbereich zu. Diese Blendenkonfiguration darf die Ausführung der GPU jedoch nicht beeinträchtigen. Die GPU befindet sich nicht im Leerlauf, wenn DxgkDdiBuildPagingBuffer mit festgelegtem DXGK_OPERATION_MAP_APERTURE_SEGMENT Vorgangstyp aufgerufen wird, und die GPU ist möglicherweise mit dem Zugriff auf andere Teile des neu konfigurierten Blendensegments beschäftigt.
Blendensegment aufheben
Mit dem Vorgang unmap-aperture-segment wird die Zuordnung eines zuvor zugeordneten Bereichs eines angegebenen Blendensegments aufgehoben. Der Treiber muss den Bereich zuordnen, der nicht der Dummyseite zugeordnet ist, die das DummyPage-Element des UnmapApertureSegment-Elements der DXGKARG_BUILDPAGINGBUFFER-Struktur angibt.

Hinweis Wenn der Treiber die Zuordnung zur Dummyseite aufhebt, muss der Treiber GPU-Zugriffe über den angegebenen Blendenbereich aktivieren, damit das DirectX-Grafikkernsubsystem Beschädigungsprobleme erkennen kann. Es gibt Konformitätstests, um diese Situation zu überprüfen.

Der Videospeicher-Manager verwendet die Dummyseite, die sich im nicht zugeordneten Teil der Blende befindet, um Probleme zu ermitteln, die der Speicher-Manager auf das Blendensegment hat.
Der Treiber kann optional MMIO verwenden, um ein Blendensegment zu konfigurieren. Die GPU greift zur Konfigurationszeit nicht auf den Blendenbereich zu. Diese Blendenkonfiguration darf die Ausführung der GPU jedoch nicht beeinträchtigen. Die GPU befindet sich nicht im Leerlauf, wenn DxgkDdiBuildPagingBuffer mit festgelegtem DXGK_OPERATION_UNMAP_APERTURE_SEGMENT-Vorgangstyp aufgerufen wird, und die GPU ist möglicherweise mit dem Zugriff auf andere Teile des neu konfigurierten Blendensegments beschäftigt.
Spezial-Lock-Übertragung
Der Spezial-Lock-Transfer-Vorgang ähnelt dem regulären Übertragungsvorgang. Anstatt jedoch den Inhalt der Zuordnung aus oder in den regulären Sicherungsspeicher der Zuordnung zu übertragen, überträgt der Vorgang für die Spezielle Sperre den Inhalt der Zuordnung von oder an die alternative virtuelle Adresse, die für die Zuordnung eingerichtet wurde, als die pfnLockCb-Funktion aufgerufen wurde, wobei das Bitfeldflag UseAlternateVA festgelegt wurde.

Der Spezialsperrungsübertragungsvorgang tritt nur in einem der folgenden Szenarien auf:
- Die Zuordnung ist derzeit cpu-zugänglich mit einer alternativen virtuellen Adresse und wird entfernt.
- Eine Zuordnung, die zuvor entfernt wurde, z. B. die im vorherigen Aufzählungszeichen beschriebene Situation, wird wieder ausgelagert.
Treiber, die die Verwendung des UseAlternateVA-Bitfeldflags nicht unterstützen, werden nicht aufgerufen, um einen spezial-lock-transfer-Vorgang auszuführen.
In einigen Szenarien kann der Treiber zum Einrichten von Hardwareressourcen erforderlich sein, wenn bestimmte Zuordnungen in oder außerhalb des Arbeitsspeichers ausgelagert werden. Standardmäßig verwendet die GPU möglicherweise die Zuordnung, auf die während des Aufrufs von DxgkDdiBuildPagingBuffer verwiesen wird. In diesen Szenarien kann es für den Treiber erforderlich sein, dass sich die Zuordnung im Leerlauf befindet, bevor der Treiber die erforderlichen Hardwareressourcen programmiert (das heißt, die Programmierung der Hardwareressourcen kann nicht im bereitgestellten DMA-Puffer in die Warteschlange eingereiht werden). In solchen Szenarien kann der Treiber den Aufruf von DxgkDdiBuildPagingBuffer mit STATUS_GRAPHICS_ALLOCATION_BUSY fehlschlagen.

Wenn der Treiber STATUS_GRAPHICS_ALLOCATION_BUSY zurückgibt, wartet der Videospeicher-Manager, bis die GPU mit einem Verweis auf die aktuelle Zuordnung fertig ist, und ruft dann die DxgkDdiBuildPagingBuffer-Funktion des Treibers erneut auf. Beim zweiten Aufruf von DxgkDdiBuildPagingBuffer legt der Videospeicher-Manager das Bitfeldflag AllocationIsIdle im Flags-Member des SpecialLockTransfer-Elements der DXGKARG_BUILDPAGINGBUFFER-Struktur fest, um anzugeben, dass die Zuordnung, auf die verwiesen wird, im Leerlauf liegt. Wenn das Leerlaufflag nicht festgelegt ist, sollte der Treiber immer feststellen, dass die Zuordnung entweder aktuell ausgelastet ist oder bald ausgelastet ist. Wenn das Idle-Flag festgelegt ist, garantiert der Videospeicher-Manager, dass die Zuordnung, auf die verwiesen wird, für die Dauer des Aufrufs von DxgkDdiBuildPagingBuffer im Leerlauf verbleibt.

Wenn der Treiber eine Hardwarepertur verwenden muss, um eine geschwenkte Zuordnung zu linearisieren, auf die eine Anwendung direkt zugreifen kann, muss der Treiber diese Zuordnung aufheben, während der Treiber die Zuordnung an den Systemspeicher überträgt, um die Kohärenz der virtuellen Adresse der Zuordnung aufrechtzuerhalten. Der Treiber muss die Zuordnung aufheben, da eine Entfernung auftreten kann, während die Anwendung auf die Zuordnung zugreift.

Der Speicher-Manager des Systems stellt sicher, dass die Übertragung für die Anwendung unsichtbar ist. Da sich die Zuordnung jedoch im Systemspeicher befindet und die virtuelle Adresse der Zuordnung nicht mehr durch die Hardwareöffnung gehen kann, muss der Treiber sicherstellen, dass die Bytereihenfolge im Systemspeicher mit dem übereinstimmt, was durch die Blende sichtbar war.

DxgkDdiBuildPagingBuffer sollte als ausgelagert werden.

Beispiele

Im folgenden Codebeispiel wird die Verwendung von DxgkDdiBuildPagingBuffer veranschaulicht.

NTSTATUS ntStatus;
DXGKARG_BUILDPAGINGBUFFER param;

// The driver receives the following paging operation to build:
//
param.Flags = 0;
param.pDmaBuffer= CurrentPagingBuffer;
param.DmaSize = CurrentPagingBufferSizeLeft;
param.pDmaBufferPrivateData = CurrentPagingBufferPrivateData; 
param.DmaBufferPrivateDataSize = CurrentPagingBufferPrivateDataSizeLeft; 
param.Operation = DXGK_OPERATION_TRANSFER; 
param.Transfer.Flags = 0; 
param.Transfer.TransferOffset = CurrentOffsetInAllocationBeingTransfered; 
param.Transfer.hAllocation = DriverContextForAllocationBeingMoved; 
param.Transfer.Source.SegmentId = 0; // Source is an MDL. 
param.Transfer.Source.pMdl = MDLDescribingPagesForAllocationBeingMoved; 
param.Transfer.Destination.SegmentId = 1; // Source to segment #1. 
param.Transfer.Destination.SegmentAddress = 0; // Source to offset 0 of segment #1.

// The driver receives MultipassOffset when it is initialized to zero 
// and uses it for multiple iterations of the paging operation.
//
param.MultipassOffset = 0;

do {
    // Call the driver's BuildPagingBuffer function to build a paging buffer.
    //
    ntStatus = BuildPagingBuffer(hAdapter, &param);
    // BuildPagingBuffer updates the size that is left in the 
    //  paging buffer with the amount of bytes that were written.
    //
    if (NT_SUCCESS(ntStatus)) {
        //
        // If STATUS_SUCCESS, batch the paging buffer to the 
        // scheduler after multiple paging operations are batched.
    }
    else if (ntStatus == STATUS_GRAPHICS_INSUFFICIENT_DMA_BUFFER) {

        //
        // If STATUS_GRAPHICS_INSUFFICIENT_DMA_BUFFER, submit the current paging buffer to the scheduler to let 
        // the GPU start working on a partial transfer.
 
        VidSchSubmitPagingBuffer(CurrentPagingBuffer, CurrentPagingBufferSizeLeft);
 
        // Acquire a new paging buffer to complete the transfer.
        //
        VidMmAcquirePagingBuffer(&CurrentPagingBuffer, &CurrentPagingBufferSizeLeft);
    }
    else {
        //
        // A critical failure occurred, so bugcheck the system. 
        // This situation should never occur because the driver can 
        // fail the call only if it requires more DMA buffer space.
    }
} while(!NT_SUCCESS(ntStatus))