Re: [libvirt] [RFC PATCH 0/4] powerpc : Libvirt for the PowerPC platform
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.
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.
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.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|