From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZKv2-0006Uc-MT for qemu-devel@nongnu.org; Tue, 08 Sep 2015 11:34:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZKuz-0002nR-Un for qemu-devel@nongnu.org; Tue, 08 Sep 2015 11:34:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZKuz-0002nJ-Kz for qemu-devel@nongnu.org; Tue, 08 Sep 2015 11:34:45 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 4C7232E6CFA for ; Tue, 8 Sep 2015 15:34:45 +0000 (UTC) Message-ID: <1441726482.14506.22.camel@redhat.com> From: Andrea Bolognani Date: Tue, 08 Sep 2015 17:34:42 +0200 In-Reply-To: <20150908143702.GG4307@redhat.com> References: <1441718858.14506.1.camel@redhat.com> <20150908143702.GG4307@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Target vs architecture for QEMU binary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org 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]. > > 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. > > 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. Cheers. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1260753 [2] If I'm not mistaken, qemuCaps->arch is set in virQEMUCapsInitArchQMPBasic() and none of the logic you're talking about seems to be used there. -- Andrea Bolognani Software Engineer - Virtualization Team