I wrote here about how to build PV drivers for Linux using the unmodified_drivers directory from Xen. The problem with this method is that you need to Xenify an existing kernel. And although the process can be automated a little, it still requires someone to keep Xen patches in sync with the kernel. That’s hard work for someone, and certainly too hard work for me.
So I simplified things. By stripping out only the files that are actually used when building the PV drivers, and putting them into a normal kernel build configuration, I can now build PV drivers for a fully HVM kernel (i.e. a normal kernel), just by adding a patch. This has the great merit you can use it with a kernel package from an arbitrary distribution.
To install, simply apply this patch to your kernel build tree, and build as normal.
- To turn it on, you need to switch on the relevant config file option (either CONFIG_XEN_PVDRIVERS=y or CONFIG_XEN_PVDRIVERS=m).
- The main changes are the location of files.
- I have imported a spaghetti of .h files. These are all included, one way or another. Most of them are pointlessly included. These could be pruned, but that would make them less easy to maintain.
- Supporting building otherwise than as a module (CONFIG_XEN_PVDRIVERS=y) was non-trivial because the code did all sorts of strange and I believe unnecessary things when MODULE was not defined if CONFIG_XEN was false too. I suspect this may not have been tested in recent times. Rather than work out what it was doing, I changed MODULE in the source to another keyword which is always defined as true. Though this now works, it is less tested. It seems not to modprobe the vbd devices correctly; I suspect it may need a MOD_ALIAS_BLOCKDEV_MAJOR in or something.
- I rewrote the Makefile and build system for the pvdrivers.
- I think the remaining code changes boil down to renaming the function ctrl_alt_del(), which is used elsewhere in the kernel which broke non-modular compilation.
- It will not work with CONFIG_XEN turned on. Whilst you don’t need CONFIG_XEN turned on for a fully HVM kernel, I can see why you might want a dual use kernel. The only reason it won’t work is namespace collisions. This is probably fixable at some cost to maintainability.