[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Third release of GPL'd PV drivers for Windows
This is the third 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.1 (64 bit Hypervisor) and Windows 2003 sp2 (32 bit PAE). YMMV. You can download the source zip file at http://www.meadowcourt.org/WindowsXenPV-0.0.3.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. It now seems fairly sane in use, I haven't had a crash for a while, but I haven't done nearly enough testing yet. 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/include/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. To install, browse to the drivers on your test server and select as a driver for the 'Unknown PCI' device, and then for the 'vbd' device which gets created by the Xen PCI driver. I've probably omitted some vitally important step from the above, so please let me know if you need any assistance compiling. To get the drivers to automatically probe your block devices on boot, you'll need to add /GPLPV to your boot.ini file. I haven't figured out a nice way of stopping windows loading the qemu Intel IDE drivers yet though (the best I got was to change the PCI ID). So you might have problems if you do it that way. The next best option is to do a block-attach at runtime, eg: xm block-attach virtdemo phy:/dev/vg00/virt-virtdemo-1 /dev/hdc w I'm pretty sure that you need to specify the 'phy:' otherwise the backend doesn't seem to publish the block and sector sizes correctly. If you do the block-attach, then your block device should show up under windows, and you can partition it etc. Changes: . I think i've fixed all the race conditions etc that were causing hangs . Fixed lots of crashes . Can now add multiple block devices . Detects the block device size correctly The source code still needs a tidy up. The Windows DDK stuff has its 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 figure out what coding style to use and where. Major limitations . Need a way to disable the qemu provided Intel IDE device when /GPLPV is specified... . Only tested under 32-bit PAE Windows 2003. Almost certainly won't work under 64 bit . Doesn't unload properly . No power management . Almost certainly won't support migration or suspend/resume. . Probably really poor performance - no optimisation done at all yet. . 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. As soon as I can get it booting nicely i'll release some binaries so it can get some more general testing. Future plans: . Improve performance. Currently I have to do a memcpy between the buffers Windows provides and Xen's buffers, because it was the easiest way. But Windows appears to mostly give buffers aligned to a multiple of 512 bytes (sector size) which may allow me to just grant Dom0 access to the page... although what happens to the other bytes in the page? . 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) (Andy Grover is looking at this) . virtual scsi (eg a front end for the scsi passthrough stuff) . balloon drivers (this should actually be pretty easy) Enjoy! James _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |