Hi Daniel, Thanks for taking time to review this. On Mon, 10 Oct 2011 11:09:34 +0100 "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list