Xen has always supported a wide variety of operating systems as guests while the host-side has always been less bright. Infact, at the moment, most of the host choice is basically around Linux or NetBSD. Seemingly, a renewed interest into improving the FreeBSD support for XEN may drastically change the landscape by adding a further options for hosts. In the last few months, infact, a collaborative effort has been started in order to bring FreeBSD support for XEN to the state of the art and possibly to the same performance as Linux.
FreeBSD-CURRENT XEN support is pretty much the same since the last three years. More precisely, it is defined by the following set of cases (please note: for the reminder of the post, as FreeBSD nomenclature demands, i386 is 32-bit version of x86 architecture while amd64 is the 64-bit version):
- No Dom0 support.
- PV support, for i386: kernel support to run FreeBSD as a paravirtualized guest, including PV frontend drivers for blk and net. Specific only to i386 archiecture.
This post written collaboratively by Attilio Rao and George Dunlap
Operating systems are generally written assuming that they are in direct control of the hardware. So when we run operating systems in virtual machines, where they share the hardware with other operating systems, this can sometimes cause problems. One of the areas addressed by a recently proposed patch series is the problem of spinlocks on a virtualized system. So what exactly is the problem here, and how does the patch solve it? And what is the effect of the patch when the kernel is running natively?
Spinlocks and virtualization
Multiprocessor systems need to be able to coordinate access to important data, to make sure that two processors don’t attempt to modify things at the same time. The most basic way to do this is with a spinlock. Before accessing data, the code will attempt to grab the spinlock. If code running on another processor is holding the spinlock, the code on this processor will “spin” waiting for the lock to be free, at which point it will continue. Because those waiting for the spinlock are doing “busy-waiting”, code should try to hold the spinlock only for relatively short periods of time.