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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list