This is the first release of my GPL'd PV drivers for Windows. Only block
device drivers so far. Also only really useful to anyone who knows
something about windows driver development.
My test environment is Xen 3.1.0 and Windows 2003 sp2. YMMV.
You can download the source zip file at
http://www.meadowcourt.org/WindowsXenPV-0.0.1.zip. No binary release
yet.
Please do not in any way consider it ready for production use.
Definitely do not use them on a production DomU. While I have never seen
them cause a problem with the hypervisor or Dom0, I would also be very
wary of using them on a production physical machine too. There is still
at least one race condition in there that hangs Windows after a fairly
short time (eg after a few minutes of doing a copy of
C:\Windows\System32).
I haven't got to probing device sizes yet, it only supports a single
device of 1048756 * 512 bytes (eg ~500mb), so make your virtual device
this size. The drivers currently do not enumerate existing block
devices, so if you want to use them you'll have to attach a device at
runtime after installing the PV drivers, eg:
xm block-attach virtdemo phy:/dev/vg00/virt-virtdemo-1 /dev/hdc w
Then your block device will show up under Windows.
To build, you'll need the Windows WDF 6000 (not the later one which is
Longhorn only I think) which you can get from Microsoft. It's not small.
You'll also need the xen/common/public folder from the xen source tree,
which needs to be in common/include/public in the Windows PV drivers
source tree. I've been doing checked build's and using Dbgview from
SysInternals for testing. Run 'build' from both the xenpci and xenvbd
folders, then copy everything from target up to your test server.
I've probably omitted some vitally important step from the above, so
please let me know if you need any assistance compiling.
To install the drivers, find the Xen PCI driver (probably an Unknown
Device in Device Manager) and install from the directory where you put
the compiled drivers. After the PCI driver installs, everything under
/device will be enumerated (eg vbd, vif, etc), again as 'Unknown
Device'. There is only currently a driver for vbd. Install that the same
way.
Once you've done that, attach the block device with the above 'xm
block-attach' command, and a disk should show up. Partition and format
the disk with the Disk Management thing in Computer Management under
windows. If you try and add a second disk it will blow up.
The source code really needs a tidy up. The Windows DDK stuff has it's
own coding style which I've imitated in places, and then xen has it's
own too, so this code is mostly one, the other, both, or neither. I'll
get to that as soon as I get the major bugs out.
Known limitations (eg things that prevent it actually being useful):
. A race condition or something like that is causing a hang.
. Only supports a single block device
. Doesn't unload properly
. Sometimes doesn't attach properly (haven't looked into this, but it
sometimes doesn't notice me attaching block devices...)
. Block device must be exactly 1048756 * 512 bytes in size
. No power management
. Almost certainly won't support migration or suspend/resume.
. Does not automatically enumerate existing block devices
. Does not support booting from a PV block device (due to the above, and
probably for other reasons)
. Probably really poor performance - no optimisation done at all yet. It
crashes too soon to be able to run any testing on at this point.
. I'm not sure that I've implemented the block device in a way that
Microsoft would approve of (eg maybe not guaranteed to work under newer
windows operating systems)... maybe it should be a scsi miniport driver,
except those have other requirements that don't mesh well with xen.
. Probably lots of other things too.
Once I've sorted out a few of the above issues I'll put together a
binary release.
Future plans:
. Virtual IRQ's... not sure if I can do this under Windows... everything
is just a port event handler currently.
. Better resource allocation to drivers (eg the PCI enumerator should be
able to hand out IRQ's and address space to the lower drivers, which
would make the scsi miniport driver do-able).
. proper shutdown (need a user space driver to do this)
. network adapters (vif)
. virtual scsi (eg a front end for the scsi passthrough stuff)
. balloon drivers (this should actually be pretty easy)
Enjoy!
James
PS. Does anyone have any objections to discussing these drivers on the
xen-devel mailing until I can set up a windows specific list somewhere?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home