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

[Daniel P. Berrange]

On Fri, Oct 14, 2011 at 01:20:01PM +0530, Prerna Saxena wrote:
> On 10/13/2011 06:53 PM, Jiri Denemark wrote:
> >On Thu, Oct 13, 2011 at 17:48:52 +0530, Prerna Saxena wrote:
> >>>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 ??
> >
> >That's not the right approach. The code that needs to be used to generate qemu
> >command line doesn't depend on the architecture on which libvirtd is running
> >but rather on the architecture of the domain you're going to start. There's no
> >reason you should not be allowed to run qemu-system-ppc64 in purely emulating
> >mode on x86_64 host. We should not artificially disable this usage.
> >
> >Jirka
> >
> 
> Hi Jirka,
> Thanks for pointing it out-- this aspect had escaped my attention.
> I'll work on how we can create an additional interface which would
> let libvirt choose appropriate devices at runtime, depending on
> guest domain
> architecture.

If you have a virDomainDefPtr object instance, you can look at the field

   def->os.arch

and make decisions from that.

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 :|