Re: [Qemu-devel] Target vs architecture for QEMU binary

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Sep 08, 2015 at 05:34:42PM +0200, Andrea Bolognani wrote:
> On Tue, 2015-09-08 at 15:37 +0100, Daniel P. Berrange wrote:
> > > at the moment, libvirt is using some ad-hoc logic to allow
> > > i686 guests to run on qemu-system-x86_64 (by using the CPU
> > > model qemu32); in all other cases, it's assumed that a $arch
> > > guest needs qemu-system-$arch to run.
> > > 
> > > This is causing a problem right now with ppc64le guests
> > > because, even though qemu-system-ppc64 is perfectly capable
> > > of running them, libvirt will refuse to.
> > 
> > Is there a bug report somewhere for that, because libvirt
> > already has code in virQEMUCapsFindBinaryForArch() which
> > forces it to look at qemu-system-ppc64 when asked to use
> > ppc64le, so I'd expect it to already work.
> 
> You're right, starting a guest actually works.
> 
> The bug report[1] (which was filed by none other than myself :)
> is still related to figuring out stuff starting from the guest
> architecture, but it's apparently going through a different
> code path where the adjustment you're referring to is not
> applied[2].

Ok, thanks I see the codepath now.

> > > We want to change the logic so that it reflects the actual
> > > capabilities of the QEMU binary, but AFAICT there isn't eg.
> > > a QMP command we can use to query the binary for the list
> > > of architectures it implements.
> > > 
> > > Am I missing something? Is such an interface available?
> > 
> > We have a bit of a chicken and egg problem, because to query
> > QEMU for capabilities, you already have to know what system
> > emulator binary is required for the architeture you want to
> > run.
> 
> Or we could just query everything that looks like a QEMU
> binary and then lookup the correct one for the guest based
> on the query results, couldn't we? Again, assuming such
> interface even exists.

I'd prefer libvirt to not have a trawl through every QEMU
binary to do this really.

> > > Failing that, we'll have to map QEMU targets with implemented
> > > guest architectures inside libvirt, in which case it would be
> > > great if you could point me towards either some up-to-date
> > > documentation or a reliable way to extract the information
> > > myself.
> > 
> > The various rules in virQEMUCapsFindBinaryForArch() already
> > try todo a suitable mapping
> 
> I'm not sure they're covering all possible combinations,
> though. Which is why it would be really nice to be able to
> ask this stuff to QEMU itself.

So, I think what we need do is to just refactor the
virQEMUCapsFindBinaryForArch(), to pull out the
architecture canonocalization out into a separate
method eg virArch virQEMUCapsCanonicalSystemArch(virArch)
and then just call it from both places

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