[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] OpenXCI update (almost ready to release an alpha version)

  • To: xen-users@xxxxxxxxxxxxx
  • From: Andrew Warkentin <andreww591@xxxxxxxxx>
  • Date: Tue, 25 Feb 2014 04:05:02 -0700
  • Delivery-date: Tue, 25 Feb 2014 11:07:55 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

Some of you may remember my post about OpenXCI quite a while ago. I have still been working on it, and am almost ready to release an alpha version.

OpenXCI is a lightweight desktop-oriented Xen/Linux distribution similar to XenClient (in other words, a dedicated dom0, onto which you install full general-purpose domUs). Unlike XenClient, it does not have any support for remote provisioning and is intended for people who just want to run multiple operating systems on one computer.

Features of the alpha version:
* Full suport for graphics passthrough
- Primary passthrough is supported for many AMD/ATI and Intel GPUs, and secondary passthrough is supported for all passthrough-compatible GPUs). NVIDIA primary passthrough may be added later, although secondary passthrough should work for any passthrough-compatible GPU

* Switching of VMs with key combinations, implemented through lightweight graphics and input servers somewhat like those in XenClient 2.x - Only a single VM may have the GPU passed through, like in XenClient 1.x/2.x - Unlike in XenClient, the graphics server does not include any GPU-specific drivers and does not do any filtering of commands sent to the GPU, meaning hardware support is much broader than XenClient 2.x - Instead of filtering of GPU commands, switching of the display while a GPU passthrough VM is running is implemented by running a special viewer on the passthrough VM (the viewer runs full-screen when a non-passthrough VM, and hides itself when the passthrough VM is focused). Both a patched VNC viewer and a viewer using a shared memory buffer are supported (the shared memory viewer is only available on Linux at the moment; a kernel driver would probably be required on Windows) - When no passthrough VM is running, the dom0 kernel's framebuffer console drivers are used instead. The framebuffer console drivers are automatically unloaded when a passthrough VM is started and re-loaded when it is shut down

* Simple GUI based on nano-X and FLTK
- Currently extremely basic; the only things supported at the moment are shutting down the entire system and launching utilities (a terminal running xentop is started automatically to provide a list of VMs, as well as a terminal displaying the system log) - Like in XenClient, it can be switched to with key combinations like a normal VM, although it runs on dom0 and is not implemented with a separate UIVM (unlike XenClient 1.x/2.x) - The nano-X server is a client of the graphics and input servers; no guest VMs display through it (unlike NxTop and XenClient Enterprise, where both the dom0-based GUI and guest VMs display through an X server on dom0)

* xl toolstack (I had originally planned to use the XCI toolstack, hence the name OpenXCI, but xl is similar enough to the XCI toolstack that there wouldn't be much of an advantage to switching)
- Support for OpenXCI-specific features has been added
- The libxl PCI device reset code has been replaced with a call to a Python script using xend's PCI reset code (the libxl reset code depends on the kernel to reset the device properly, and the kernel reset code only seems to work on devices supporting FLR; the xend reset code is capable of resetting many devices that don't support FLR)

* Currently based on Debian 6.0, Xen 4.1, and Linux kernel 3.9.7 from OpenSUSE (this is a kernel based on a forward-ported version of the old Xenlinux patches; it seems to be more stable with GPU passthrough than the pvops kernels that I tried) - Will probably be updated to later versions eventually; I had a version based on Xen 4.3, but it hung on me quite often, whereas the Xen 4.1 version seems to be more stable - Support for blktap2 (but not blktap1) was restored (Debian disabled it for some reason)

Currently I am just in the process of packaging everything so I can put together an ISO. I am going to upload the source to the OpenXCI Sourceforge page <http://sf.net/projects/openxci>.

I am running OpenXCI exclusively on my main PC (no multi-boot with regular bare-metal OS installs at all), which is based on a Core i7-960, Intel DX58SO, and Radeon 5770. I am running Solaris, Linux, Windows XP, NetBSD, and FreeBSD domUs (with both an Ubuntu domU and a WinXP one configured for GPU passthrough; I can only run one at a time since I have only one graphics card). There are still a few stability issues with it, although dom0 crashes seem pretty rare. The issues mostly seem to relate to dom0 giving up and taking back the GPU, as well as some with the Ubuntu domU that I'm running; however, one issue I have not had is the performance degradation on domU reboot that some people report with AMD/ATI GPUs (neither with Linux, nor with Windows). That might be because I am using primary passthrough; I'm not quite sure.

I am also in the process of writing another Xen-based hypervisor called RT/XH, which will be based on a very different architecture from a standard Xen system. Instead of a Unix dom0, it will use a collection of stubdoms (there will still be a dom0, but it will be a stubdom as well, handling only supervision of other domains; each driver or service will run in its own stubdom). These stubdoms will be based on a combination of RTEMS and the NetBSD rump kernel (as well as a dynamic linker so that programs running in stubdoms don't have to be statically linked with the kernel), rather than mini-OS. Backends on domains running normal general-purpose OSes will of course still also be supported. The paravirtualized I/O interface will be different than that of standard Xen as well (it will be more object-oriented and will require less boilerplate in frontend drivers), although traditional Xen PV backends will still be available. I am also planning to improve Xen's support for real-time scheduling (as the name RT/XH might suggest, I am wanting it to have proper realtime support so it can be used in embedded systems requiring hard realtime, as well as desktops). I am basically just intending OpenXCI to be a stopgap until RT/XH is ready, since RT/XH will do everything OpenXCI can and more, while being more reliable than Xen with a dom0 based on a monolithic-kernel Unix (it will be designed to allow crashed drivers to either be auto-restarted or at least fail gracefully). I think current Xen systems don't take full advantage of the fact that Xen is a microkernel. It's generally not thought of as one, but I would consider it to be a kind of microkernel. I would define a microkernel as a kernel that only includes scheduling, IPC, and low-level memory management, regardless of whether the environment it presents to programs running on top of it is based on threads/messages, domains/VCPUs/interrupts, or something else entirely.

If anyone here wants to contribute to either OpenXCI or RT/XH, they are definitely welcome.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.