Export (0) Print
Expand All

IOCTL_VPCI_INVALIDATE_BLOCK control code

The driver for a PCI Express (PCIe) virtual function (VF) issues the IOCTL_VPCI_INVALIDATE_BLOCK IOCTL request in order to be notified of changes to data in one or more VF configuration blocks. The driver is notified of these changes when the IOCTL is completed. Once notified, the driver should assume that any data previously read from the specified VF configuration blocks has become invalid. Therefore, the driver should update its cache by reading the configuration block data again.

The driver issues this IOCTL to the next-lower driver in the driver stack.

Note  This IOCTL request is issued by the driver of a PCIe VF on a device that supports the single root I/O virtualization (SR-IOV) interface.

When the driver issues the IOCTL_VPCI_INVALIDATE_BLOCK IOCTL, the driver must follow these steps:

Preparing an I/O Request Packet Structure

Preparing an I/O Stack Location Structure

Issuing the IOCTL Request

IOCTL Request Completion Results

For more information about issuing IOCTLs between kernel-mode drivers, see Creating IOCTL Requests in Drivers.

Preparing an I/O Request Packet Structure

The driver must first allocate or reuse an I/O request packet (IRP). You can use the IoBuildDeviceIoControlRequest routine to specifically allocate an IOCTL IRP. You can also use general-purpose IRP creation and initialization routines, such as IoAllocateIrp, IoReuseIrp, or IoInitializeIrp. For more information about IRP allocation, see Creating IRPs for Lower-Level Drivers.

The driver must then set the members of the IRP structure as described in the following table.

IRP memberValue
UserBuffer

NULL

UserEvent

The address of the event object that was initialized in the call to the KeInitializeEvent routine.

Note  If asynchronous completion of the IOCTL request is not required, this member should be set to NULL. For more information, see Creating IOCTL Requests in Drivers.
UserIosb

The address of a caller-allocated IO_STATUS_BLOCK structure. This structure is updated by the lower driver to indicate the final status of the I/O request.

 

Preparing an I/O Stack Location Structure

The driver calls the IoGetNextIrpStackLocation routine to access the lower driver's I/O stack location. This function returns a pointer to an IO_STACK_LOCATION structure that contains the parameters for the I/O stack location.

The driver must then set the members in the IO_STACK_LOCATION structure as described in the following table.

IO_STACK_LOCATION memberValue

MajorFunction

IRP_MJ_INTERNAL_DEVICE_CONTROL

Parameters.DeviceIoControl.IoControlCode

IOCTL_VPCI_INVALIDATE_BLOCK

Parameters.DeviceIoControl.Type3InputBuffer

A pointer to a VPCI_INVALIDATE_BLOCK_OUTPUT structure. The driver formats this structure with the parameters for the IOCTL_VPCI_INVALIDATE_BLOCK I/O request.

I

Parameters.DeviceIoControl.InputBufferLength

The size, in bytes, of the VPCI_INVALIDATE_BLOCK_OUTPUT structure.

Parameters.DeviceIoControl.OutputBufferLength

The size, in bytes, of the caller-allocated buffer that will contain the configuration data to be read.

Note  This value must be the same as the value of the BytesRequested member of the VPCI_INVALIDATE_BLOCK_OUTPUT structure.

 

Issuing the IOCTL Request

To issue this IOCTL request, the driver calls the IoCallDriver routine to pass the request on to the next-lower driver in the driver stack. The driver sets the parameters of IoCallDriver as described in the following table.

IoCallDriver parameterValue
DeviceObject

The device object of the lower driver.

Irp

The address of the IRP that was previously allocated and initialized. For more information, see Preparing an I/O Request Packet Structure.

 

IOCTL Request Completion Results

When the IOCTL_VPCI_INVALIDATE_BLOCK IOCTL request is completed, the members of the caller-allocated IO_STATUS_BLOCK structure are set to the values in the following table.

Status valueValue
Status

STATUS_SUCCESS

Information

Zero

 

Remarks

When the IOCTL_VPCI_INVALIDATE_BLOCK IOCTL is issued and completed, the VF driver is notified that the PF driver has changed (invalidated) data in one or more VF configuration blocks.

Note  The operating system reserves and manages the resources that are required for the successful completion of this IOCTL.

A VF configuration block is used for backchannel communication between the drivers of the PCIe PF and a VF on a device that supports the SR-IOV interface. VF configuration data can be exchanged between the following drivers:

  • The VF driver, which runs in the guest operating system. This operating system runs within a Hyper-V child partition.

  • The PF driver, which runs in the management operating system. This operating system runs within the Hyper-V parent partition.

Starting with NDIS 6.30, the VF miniport driver should not issue an IOCTL_VPCI_INVALIDATE_BLOCK request. Instead, the following steps are performed in order to handle notifications of invalidated VF configuration block data.

  1. In the guest OS, NDIS issues an IOCTL_VPCI_INVALIDATE_BLOCK request.

  2. In the management OS, the following steps occur:

    1. The PF miniport driver calls the NdisMInvalidateConfigBlock function to notify NDIS that VF configuration data has changed and is no longer valid. The driver sets the BlockMask parameter to a ULONGLONG bitmask that specifies which VF configuration blocks have changed. Each bit in the bitmask corresponds to a VF configuration block. If a bit is set to one, the data in the corresponding VF configuration block has changed.
    2. NDIS signals the virtualization stack, which runs in the management OS, about the change in VF configuration block data. The virtualization stack caches the BlockMask parameter data.

      Note  Each time that the PF miniport driver calls NdisMInvalidateConfigBlock, the virtualization stack ORs the BlockMask parameter data with the current value in its cache.
    3. The virtualization stack notifies the virtual PCI (VPCI) driver, which runs in the guest OS, about the invalidation of VF configuration data. The virtualization stack sends the cached BlockMask parameter data to the VPCI driver.

  3. In the Guest OS, the following steps occur:

    1. The VPCI driver saves the cached BlockMask parameter data in the BlockMask member of the VPCI_INVALIDATE_BLOCK_OUTPUT structure that is associated with the IOCTL_VPCI_INVALIDATE_BLOCK request.

    2. The VPCI driver successfully completes the IOCTL_VPCI_INVALIDATE_BLOCK request. When this happens, NDIS issues an object identifier (OID) request of OID_SRIOV_VF_INVALIDATE_CONFIG_BLOCK to the VF miniport driver. A pointer to an NDIS_SRIOV_VF_INVALIDATE_CONFIG_BLOCK_INFO structure is passed along in the OID request. This structure contains the cached BlockMask parameter data.

      NDIS also issues another IOCTL_VPCI_INVALIDATE_BLOCK request to handle successive notifications of changes to VF configuration data.

    3. When the VF driver handles the OID_SRIOV_VF_INVALIDATE_CONFIG_BLOCK request, it reads data from the specified VF configuration blocks.

Note  The usage of the VF configuration block and the format of its configuration data are defined by the independent hardware vendor (IHV) of the device. The configuration data is used only by the drivers of the PF and VF.

Requirements

Version

Supported in Windows Server 2012 and later versions of Windows.

Header

Vpci.h (include Wdm.h)

IRQL

DISPATCH_LEVEL

See also

Creating IOCTL Requests in Drivers
IoCallDriver
IO_STATUS_BLOCK
IO_STACK_LOCATION
IRP
IRP_MJ_INTERNAL_DEVICE_CONTROL
NDIS_SRIOV_VF_INVALIDATE_CONFIG_BLOCK_INFO
NdisMInvalidateConfigBlock
OID_SRIOV_VF_INVALIDATE_CONFIG_BLOCK
VPCI_INVALIDATE_BLOCK_OUTPUT

 

 

Send comments about this topic to Microsoft

Show:
© 2015 Microsoft