Difference between revisions of "Xen Windows GplPv"
(Removed some broken links)
Revision as of 10:35, 12 January 2012
These drivers allow Windows to make use of the network and block backend drivers in Dom0, instead of the virtual PCI devices provided by QEMU. This gives Windows (in theory) a substantial performance boost, and most of the testing that has been done confirms that. This document refers to the new WDM version of the drivers, not the previous WDF version. Some information may apply though.
Supported Xen versions
I am using Xen 3.1.x and 3.2.x from Debian for my testing. I tested with 3.0.x by mistake once and it crashed my Dom0 hard, so don't expect these drivers to work under anything lower than 3.1.x
Update: Gplpv >=0.11.0.213 were tested for a long time on Xen 4.0.x and are working, should also be working on Xen 4.1.
Supported Windows versions
In theory the drivers should work on any version of Windows supported by Xen. With their respective installer Windows 2000 and later to Windows 7, 32 and 64-bit, also server versions.
Recent binaries are available from http://www.meadowcourt.org/downloads/
- There is now one download per platform/architecture, named as follows:
gplpv <platform><arch> <version> <debug>.msi
- platform is '2000' for 2000, 'XP' for XP, '2003' for 2003, and 'Vista2008' for Vista/2008/7
- arch is 'x32' for 32 bit and 'x64' for 64 bits
- 'debug' if is build which contains debug info (please use these if you want any assistance in fixing bugs)
- without 'debug' build which contains no debug info
You can get signed GPLPV drivers from uninvention. For install on Vista and later without activating the testsigning.
Installing / Upgrading
Once built (or downloaded for a binary release), the included NSIS installer should take care of everything. See here for more info, including info on bcdedit under Windows 2008 / Vista.
/!\ Please definitly visit the link above which links to /Installing . It holds information to not crash your Installation. It concerns the use of the /GPLPV boot parameter.
Previous to 0.9.12-pre9, '/GPLPV' needed to be specified in your boot.ini file to activate the PV drivers. As of 0.9.12-pre9, /NOGPLPV in boot.ini will disable the drivers, as will booting into safe mode. With 'shutdownmon' running, 'xm shutdown' and 'xm reboot' issued from Dom0 should do the right thing too.
In your machine configuration, make sure you don't use the ioemu network driver. Instead, use a line like:
vif = 
Also fixed MAC address can be set,useful to the risk of reactivation of a license for Windows.
- An OpenSolaris Dom0 is reported not to work, for reasons unknown.
- Checksum offload has been reported to not work correctly in some circumstances.
- Shotdown monitor service in some cases is not added, and must be added manually
Using the windows debugger under Xen
Set up Dom0
- Change/add the serial line to your Windows DomU config to say serial='pty'
- Add a line to /etc/services that says 'windbg_domU 4440/tcp'. Change the domU bit to the name of your windows domain.
- Add a line to /etc/inetd.conf that says 'windbg_domU stream tcp nowait root /usr/sbin/tcpd xm console domU'. Change the domU bit to the name of your domain. (if you don't have an inetd.conf then you'll have to figure it out yourself... basically we just need a connection to port 4440 to connect to the console on your DomU)
- Restart inetd.
Set up the machine you will be debugging on - another Windows machine that can connect to your Dom0 from.
- Download the windows debugger from Microsoft and install.
- Download the 'HW Virtual Serial Port' application from HW Group and install. Version 3 appears to be out, but i've only ever used 2.5.8.
Boot your DomU
- xm create DomU (or whatever you normally use to start your DomU)
- Press F8 when you get to the windows text boot menu and select debugging mode, then boot. The system should appear to hang before the splash screen starts
- Start the HW Virtual Serial Port application
- Put the IP address or hostname of your Dom0 in under 'IP Address'
- Put 4440 as the Port
- Select an unused COM port under 'Port Name' (I just use Com8)
- Make sure 'NVT Enable' in the settings tab is unticked
- Save your settings
- Click 'Create COM'. If all goes well it shuold say 'Virtual serial port COM8 created' and 'Connected device <hostname>'
Run the debugger
- Start windbg on your other windows machine
- Select 'Kernel Debug' from the 'File' menu
- Select the COM tab, put 115200 in as the baud rate, and com8 as the port. Leave 'Pipe' and 'Reconnect' unticked
- Click OK
- If all goes well, you should see some activity, and the HWVSP counters should be increasing. If nothing happens, or if the counters start moving and then stop, quit windbg, delete the com port, and start again from 'Start HWVSP'. Not sure why but it doesn't always work the first time.
- The debug output from the PV drivers should fly by. If something isn't working, that will be useful when posting bug reports.
- If you actually want to do some debugging, you'll need to have built the drivers yourself so you have the src and pdb files. In the Symbol path, add '*SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\path_to_source\target\winxp\i386'. change winxp\i386 to whatever version you are debugging.
- Actually using the debugger is beyond the scope of this wiki page :)
- xenpci driver - communicates with Dom0 and implements the xenbus and event channel interfaces
- xenhide driver - disables the QEMU PCI ATA and network devices when the PV devices are active
- xenvbd driver - block device driver
- xennet driver - network interface driver
- xenstub driver - provides a dummy driver for vfb and console devices enumerated by xenpci so that they don't keep asking for drivers to be provided.