[libvirt] [RFC PATCH 0/4] powerpc : Libvirt for the PowerPC platform

Recent development in KVM for 64-bit Power ISA Book3S machines, allows users to run multiple KVM guest instances on POWER7 and PPC970 processor based systems. Also qemu-system-ppc64 has been enhanced to support a new machine type "pseries" suitable for Power Book3S machines. This addition effectively brings the KVM+qemu combination to run multiple guest instances on a Power Book3S machine. Libvirt continues to be the key interface to configure and manage the KVM guest instances on x86. We would like to enhance libvirt to support KVM guest configuration and management on Power Book3S machines. The following set of patches tries to illustrate the porting issues in libvirt since it has been predominantly designed and used for x86 KVM. I would like to discuss these issues and list out the possibilities of refactoring the code and make it easier for adding support for non-x86 architectures. Some of the key changes that would be needed in libvirt to manage guests on qemu-system-ppc64 'pseries' platform would be as follows: 1) A new driver would be needed for PowerPC CPU, to identify and filter supported PowerPC-CPU families. 2) A new set of interfaces would be needed to extract host system and firmware information (SMBIOS and host-OS information like CPU and memory topology, processor type, hardware threads, etc). 3) Clean abstraction of platform-specific references such as ACPI dependencies from generic domain initialization sequence. (Many such options get automatically selected by libvirt, unless they are explicitly flagged as unrequired in XML. This default list will differ for every architecture). 4) A mechanism to specify the list of allowable devices for every architecture -- the 'pseries' vm would boot with its own set of devices, some of which may not be available with x86. In order to address the above requirements, we could take one of the following implementation schemes: Approach 1: ----------- Create a new host backend for powerpc-kvm -- similar to xen, kvm, esx, etc. Advantage : Even if the qemu device model on ppc varies significantly, the difference between the device model between qemu-system-ppc64 and qemu-system-x86_64 can be easily managed. It could possibly allow easier ways of segregating supported devices, and also specifying a new set of methods to gather host system information. Drawback: - Overhead of maintaining a new backend, which is expected to have some similarities with the x86-specific 'KVM' backend. - Might get confusing for end users. Approach 2: ----------- Hack the present 'kvm' backend to add powerpc-specific features. Advantage: Having a seamless 'kvm' interface across architectures would be of more convenience to the end-user -- a single XML spec could work with only a small subset of arch-specific changes. Also, newer features that come in for one arch would be more easily ported to others. However, it would entail more run-time switches based on the host kvm architecture. One way to do this would be to add a new arch-specific layer within the 'kvm' backend. This would be compiled-in depending on the host architecture, and would expose only those features (system information, devices, features etc) which are implemented in kvm _on_that_platform_. Drawback: This will cause some rewriting of how internal qemu/kvm interfaces interact in libvirt. The attached patch series (albeit hackish in nature) attempts to illustrate the difference in the architecture and call out parts of the libvirt code that would need changes. -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India