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