Also, because there are some circumstances where SCSIFILT is not loaded (e.g. if a disk is disabled in Device Manager) both XENVBD and SCSIFILT must have code to deal with the PV state modes, for purposes of VBD unplug which is more code duplication.

Im a principal engineer in the XenServer group at Citrix and Im project lead for the XenProject Windows PV Drivers.

In my view of the world trees grow downwards so I put PDOs at the top.

Citrix Xen Windows X86 Pv Driver Attaches To

That code is called a Function Driver and when a function driver attaches to a PDO it creates a corresponding Function Device Object or FDO.

Citrix Xen Windows X86 Pv Drivers Do Not

Hence function drivers do not contain code to discover their hardware.

Instead they are part of a package described by what is called an INF file.

In that INF file there are entries to tell Windows what PDO names a particular function driver will bind to, So, as Windows builds its device tree it can look at the names of newly created PDOs and determine which Function Drivers to load.

That means that, having created its FDO, it can also create PDOs.

I believe they were written for Windows 2000 support on the first version of XenServer (or possibly even XenEnterprise) to support HVM guests.

Also, there is less and less point in doing so as time goes by.

Server 2003 will be EOL this year (2015), at which point these drivers will finally be consigned to history.

The one on the right is the Xen Platform PCI device, created by QEMU, and a key part of any HVM guest running on pretty much any Xen distribution.

The one on the left, however, is synthesized by a driver installer package.

XENEVTCHN is the ultimate parent of the PV network devices, but not the storage devices.

Those are dealt with by XENVBD, which binds directly to the PCI device, but uses code in XENUTIL to co-ordinate with XENEVTCHN.

The reason for this driver is that (because it needs to work on versions of Windows older than Vista) XENVBD uses a very old storage driver API in Windows called SCSIPORT, and SCSIPORT has very poor locking semantics and only a single request queue for an HBA.

SCSIFILT is designed to sit between the generic Windows DISK driver and the XENVBD and intercept storage requests.

Being a filter driver its not bound by any logo requirement to use a standard Windows storage API and so it bypasses the whole SCSIPORT queuing and locking framework and talks directly to the PV backends, which is a lot faster.

Because the legacy drivers used to be used for versions of Windows all the way from Server 2000 through to 7 and Server 2008R2 they actually had to have two distinct versions of the XENNET driver.

Between releasing Server 2003 and Vista Microsoft changed the NDIS API in an incompatible way, so anyone writing Windows network drivers needed to fork their code.

Server 2003 and before uses NDIS version 5.x and Vista onwards uses version 6.x.

I therefore re-wrote the drivers, moving all the common code into a driver called XENVIF which I also made the parent of all XENNETs, to allow for dynamic interface discovery which is something well come onto later.

Those requests, because they did not come from the DISK driver, bypass SCSIFILT and thus XENVBD has to have a very odd loopback path where it injects the requests into the storage stack as if they did come from the DISK driver to allow them to be intercepted by SCSIFILT.

Also, because there are some circumstances where SCSIFILT is not loaded (e.g.

Device Manager) both XENVBD and SCSIFILT must have code to deal with the PV state modes, for purposes of VBD unplug which is more code duplication.