From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBUkI-0006Yq-H3 for qemu-devel@nongnu.org; Fri, 01 Mar 2013 13:31:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBUkH-0004IZ-Cu for qemu-devel@nongnu.org; Fri, 01 Mar 2013 13:31:50 -0500 Received: from cantor2.suse.de ([195.135.220.15]:50536 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBUkH-0004IN-3h for qemu-devel@nongnu.org; Fri, 01 Mar 2013 13:31:49 -0500 Message-ID: <5130F412.3040903@suse.de> Date: Fri, 01 Mar 2013 19:31:46 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20130221145818.GK16618@otherpad.lan.raisama.net> <20130301131238.GE3375700@orkuz.home> In-Reply-To: <20130301131238.GE3375700@orkuz.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Luiz Capitulino , Jiri Denemark Cc: libvir-list@redhat.com, Igor Mammedov , qemu-devel@nongnu.org, Alexander Graf Am 01.03.2013 14:12, schrieb Jiri Denemark: > On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote: >> =3D Listing CPU models =3D >> >> Requirement: libvirt needs to know which CPU models are available to b= e used >> with the "-cpu" option. >> >> Current problem: libvirt relies on help output parsing for that. query-cpu-definitions is the QMP command to retrieve values compatible with -cpu. And if libvirt is not using it, I really don't understand why the work of maintaining this crappy interface has been pushed onto us in the first place? There is no reuse between -cpu ? and QMP implementations so it's just extra work, there is no communicated or implemented way to extend the arch_query_cpu_definitions() implementation to become more usable for command line output implementation (e.g., associating a PVR value with the model name for ppc) and, while we're at it, it uses global functions plus a stub rather than a CPUState hook with a no-op default implementation in qom/cpu.c... >> Solution: use QMP qom-list-types command. >> >> Dependency: X86CPU subclasses. >> Limitation: needs a live QEMU process for the query. >=20 > No problem, we already run QEMU and use several QMP commands to probe > its capabilities. And "qom-list-types" is actually one of them. To get > the list of CPU models, we would just call >=20 > { > "execute": "qom-list-types", > "arguments": { > "implements": "X86CPU" > } > } >=20 > right? Not quite, this would return abstract types as well, so you'd need to add "abstract": "false" or so. And you need to use the type name, not the struct name as argument, i.e. "i386-cpu" or "x86_64-cpu". Note: This does not always match the executable name since QOM names are supposed to be verbose (e.g., ppc64 vs. powerpc64-cpu) and some executables are misnamed (sh4 vs. superh-cpu)= . For x86 today this will return one type, either "i386-cpu" or "x86_64-cpu", that's why I have been pushing to implement model subclasses. There's still some controversial discussions about how this relates to KVM and TCG changing values of classes. > What about other non-x86 architectures? For some other architectures like arm this will return the full list of available classes, but in "cortex-a9-arm-cpu" format, which is not guaranteed to be compatible with -cpu but rather with -device where already applicable. > Will we need to use > different class name or is there a generic CPU class that could be used > universally? "cpu" would currently work as well, but the CPU refactorings are targetting to compile, e.g., arm-cpu and microblaze-cpu types into the same executable, so "cpu" may lead to undesired results in the future depending on what assumptions your code makes. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg