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

[Prerna Saxena]

Hi Daniel,
Thanks for taking time to review this.
On Mon, 10 Oct 2011 11:09:34 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Fri, Oct 07, 2011 at 11:58:16PM +0530, Prerna Saxena wrote:
> > 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.
> 
> Yep, we'd like to see other architectures more widely used/tested/
> supported in libvirt.

Nice to hear this.

> 
> > 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.
> 
> Ok, we were expecting that.
> 
> > 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).
> 
> Yes, we more or less expected that too.
> 
> > 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.
> 
> 
> Yep, these 2 are the bulk of the work, mostly in the qemu_command.c
> file I expect.

Yes. For starters, I'm seeing if qemu-command.c can be split into :
qemu-command-common.c
qemu-command-x86.c
qemu-command-ppc64.c

Depending on the host architecture, qemu-command-common.o could be linked
with the respective arch-specific device spec.
Makefile would resemble something like this:
...
qemu-command-y = qemu-command-common.o
qemu-command-y += qemu-command-$(TARGET_BASE_ARCH)
...

It is just an initial thought. Suggestions ??
> 
> > 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.
> 
> This approach is totally out of the question. There are many
> 1000's of lines of code in the QEMU driver, of which very little
> is architecture specific. It just would not be a good use of
> resources to fork that.
> 
> > 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.
> 
> I don't think that's a drawback actually. What you're actually doing
> here is just improving the quality of our existing driver, by removing
> some bogus assumptions it has in it. So making it work with PPC will
> benefit us in general.
> 

Agree. Let me work on interfaces that would allow libvirt to choose
default guest devices based on host architecture, for a guest running
on 'KVM' hypervisor. Will send the patches out soon.

> 
> Regards,
> Daniel



-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India