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

[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


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