Xen Gpl Pv Driver Developers Network & Wireless Cards Driver

Posted : admin | On 30-03-2021

The Windows PV Drivers are built individually into a tarball each. To install a driver on your target system, unpack the tarball, then navigate to either the x86 or x64 subdirectory (whichever is appropriate), and execute the copy of dpinst.exe you find there with Administrator privilege. For more information read the installation instructions.

Xen Gpl Pv Driver Developers Network Install
Xen Gpl Pv Driver Developers Network & Wireless Cards Drivers
Xen Gpl Pv Driver Developers Network Software

Howto install a Windows 2k8 r2 on a xen host with GPL PV drivers v0.10.0.130

I do need to de-select 'Copy Network Settings' during a custom install of gplpv. Leaving 'Copy network settings' resulted in a BSOD for me in 2008R2 x64. I run Xen 4.4.0-RELEASE built from source on Debian Jessie amd64. PV drivers 1.0.1089 tested on windows 7 x64 pro SP1, dom0 Debian Wheezy with xen 4.4 from source and upstream qemu =1.6.1.
To install a driver on your target system, unpack the tarball, then navigate to either the x86 or x64 subdirectory (whichever is appropriate), and execute the copy of dpinst.exe you find there with Administrator privilege. More information can be found here. You can also get the drivers via https://xenbits.xenproject.org/pvdrivers/win/9.0.0/.

Contents

[Update: Signed drivers can be found here]

The machine is called 'slate', and has a single 32Gbyte disk. The xen host is running (a very old) Fedora 8 with xen-3.1.2-5.fc8.

Install Server 2008 R2

Assign a lump of disk (from a LVM volume) for the operating system (32Gbytes), and boot from the installation media DVD. Use a VNC client to step through the graphical installation. Use the following 'xm' style configuration:

Note: A Windows Vista x64 machine was used as the VNC client during installation. For some reason connecting to the VNC session over a Putty SSH tunnel using the loopback interface didn't work (the connection hung during the initial handshake). Binding to the ethernet interface of the Xen host, and going directly worked well.

GPL PV Drivers

Given the Windows machine is Server 2008 R2 x64, the drivers must have 'wlh' and 'amd64' in their name. The current revision is gplpv_fre_wlh_AMD64_0.10.0.130.

The installation of the drivers was very straightforward. Given the drivers are signed for 'test mode' operation, and a certificate is provided, the pain to get the drivers installed is reasonably low. I created an ISO image with the MSI install program on it, and added the ISO image as a CDROM device. This means the qemu network adapter doesn't have to be used or configured (but this would be another way to get the drivers onto the machine).

The 'xm' style VM configuration with the gpl pv driver as a second CDROM device is:

The four steps I followed are:

set 'test signing' mode on
reboot
install driver MSI
reboot

To enable test signing mode execute:

Once the driver was installed and the machine was rebooted, I configured a static IPv4 and IPv6 address on the network adapter, and enabled remote desktop.

Device manager indicated that the driver was being used, by the presence of the 'Xen Net Device Driver' and 'Xen PV Disk SCSI Disk Device'.

Note: The shutdown service works well 'out of the box'. Shutting the machine down from the xen host with 'xm shutdown slate' performs an orderly shutdown.

Running 'xm' configuration

Once the machine is up and running:

change the boot device back to 'c' drive
change the network interface to 'type=paravirtualised' (so that qemu-dm doesn't create a tap device)

Residual Issues

Given I am running an old version of xen in domain 0 (v3.1.2), there is an issue with using the GPL PV driver such that the CDROM devices no longer function, and the 'Intel(r) 82371SB PCI Bus Master IDE Controller' device has an issue.

Upgrading to the latest xen would solve this issue.

Appendices

Windows Server 2008 R2 Installation gallery

Ready to install. Pick the time and currency format.

Select which version of the operating system to install.

Accept the license terms (like there is a real choice).

Pick custom install (this is a fresh install, not an upgrade)

The install program creates a 100MByte partition. There was no choice.

Installation begins. Note that the machine does reboot during the install.

And reboots...

Set the Administrator password

Enter a new password

Overall the installation was reasonably easy and quick.

GPL PV Driver Installation Gallery

Once the 'bcdedit /set testsigning on' is run, and the machine has rebooted, the 'test mode' should display in the lower right of the desktop.

Run the GPL PV driver installation msi.

Accept the license.

The custom install shows what will be installed. Note how the 'test mode' signing certificate is installed.

Install.

Install the drivers, and always trust the 'GPLPV_Test_Cert'.

The installation is done.

Reboot the system to activate the drivers.

After rebooting, the device manager shows the following devices (Note: the system is using Xen 3.1.2 on the host - modern xen hosts may hide more)

A driver domain is unprivileged Xen domain that has been given responsibility for a particular piece of hardware. It runs a minimal kernel with only that hardware driver and the backend driver for that device class. Thus, if the hardware driver fails, the other domains (including Dom0) will survive and, when the driver domain is restarted, will be able to use the hardware again.

As disk driver domains are not currently supported, this page will describe the setup for network driver domains.

3Setup

Xen Gpl Pv Driver Developers Network Install

Performance

This will eliminate dom0 as a bottleneck. All device backend in dom0 will result dom0 to have bad response latency.

Enhanced reliability

Hardware drivers are the most failure-prone part of an operating system. It would be good for safety if you could isolate a driver from the rest of the system so that, when it failed, it could just be restarted without affecting the rest of the machine.

Enhanced security

Because of the nature of network protocols and routing, there is a higher risk of an exploitable bug existing somewhere in the network path (host driver, bridging, filtering, &c). Putting this in a separate, unprivileged domain limits the value of attacking the network stack: even if they succeed, they have no more access than a normal unprivileged VM.

Having a system with a modern IOMMU (either AMD or VT-d version 2) is highly recommended. Without IOMMU support, there's nothing to stop the driver domain from using the network card's DMA engine to read and write any system memory. Furthermore, without IOMMU support, you cannot pass through a device to an HVM guest, only PV guests.

If you don't have IOMMU support, you can still use PV domains to get the performance benefit, but you won't get any security or stability benefits.

Setting up the driver domain is fairly straightforward, and can be broken down into the following steps:

Set up a VM with the appropriate drivers

These drivers include the hardware driver for the NIC, as well as drivers to access xenbus, xenstore, and netback. Any Linux distro with dom0 Xen support should do. The author recommends xen-tools (also see xen-tools).

You should also give the VM a descriptive name; 'domnet' would be a sensible default.

Install the xen-related hotplug scripts

These are scripts that listen for vif creation events on xenstore, and respond by doing the necessary setup with netback.

The easiest way to do this is by installing the full set of xen toolsin the VM -- either by installing the xen-utils package, or running'make install-tools' inside the VM.

Use PCI passthrough to give the VM access to the hardware NIC

This has a lot of steps, but is fairly straightforward. Details for doing so can be found here: Xen PCI Passthrough

Set up network topology in the VM

This is identical to the setup you would do in domain 0. Normally this would be bridging, but NAT or openvswitch are other possibilities. See more information at Host_Configuration/Networking.