Windows PV Drivers Presentation
Contents
- 1 Notes:
- 1.1 Slide 0
- 1.2 Slide 1
- 1.3 Slide 2
- 1.4 Slide 3
- 1.5 Slide 4
- 1.6 Slide 5
- 1.7 Slide 6
- 1.8 Slide 7
- 1.9 Slide 8
- 1.10 Slide 9
- 1.11 Slide 10
- 1.12 Slide 11
- 1.13 Slide 12
- 1.14 Slide 13
- 1.15 Slide 14
- 1.16 Slide 15
- 1.17 Slide 16
- 1.18 Slide 17
- 1.19 Slide 18
- 1.20 Slide 19
- 1.21 Slide 20
- 1.22 Slide 21
- 1.23 Slide 22
Notes:
Slide 0
Hi, I’m Paul Durrant. I’m a principal engineer in the XenServer group at Citrix and I’m project lead for the XenProject Windows PV Drivers.
Slide 1
In this presentation I’m going to be giving an overview of the drivers.
We’ll start with the origins of the drivers, and the journey from the original XenServer-specific closed-source ‘Legacy’ drivers, through the open source XenServer drivers (dubbed the ‘Standard’ drivers in Citrix and available on GitHub), to the current generic XenProject drivers, the source of which is now hosted on Xenbits.
I’ll then move on to the way that functionality is broken down into interfaces, how they are provided and consumed, and how compatibility is maintained as they evolve.
And finally I’ll give a brief overview of what you need to do to build and install the drivers, and contribute to the project.
Slide 2
To start with I need to introduce some Windows driver terminology and some conventions I’ve used in the diagrams in this presentation.
Windows devices are organized into a tree, or a set of trees, rooted at what’s called a Physical Device Object or PDO. In my view of the world trees grow downwards so I put PDOs at the top
Normally a PDO just represents a piece of hardware, which is not that useful unless you have some code to talk to it. 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.
Unlike some OS, such as Linux, Windows has a concept of demand-loading drivers. 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.
A Function Driver can also be what’s called a Bus Driver. That means that, having created its FDO, it can also create PDOs. For example, the root PCI driver binds to a PDO created by the ACPI driver (which is parsing the DSDT). It will create an FDO to bind to that, enumerate the root bus (using PCI config cycles) and create a PDO for each unique bus/device/function that it finds.
