From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c5Cpd-0008RD-Az for qemu-devel@nongnu.org; Fri, 11 Nov 2016 09:29:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c5Cpa-000207-6j for qemu-devel@nongnu.org; Fri, 11 Nov 2016 09:29:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32962) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c5Cpa-0001zx-0n for qemu-devel@nongnu.org; Fri, 11 Nov 2016 09:29:26 -0500 From: Markus Armbruster References: <1477705687-31175-8-git-send-email-ehabkost@redhat.com> <20161031150723.65138525@nial.brq.redhat.com> <20161031143605.GT5057@thinpad.lan.raisama.net> <878tsz5jw2.fsf@dusky.pond.sub.org> <20161104160421.GJ5057@thinpad.lan.raisama.net> <874m3j1zjd.fsf@dusky.pond.sub.org> <20161107123858.GO5057@thinpad.lan.raisama.net> <878tsvs686.fsf@dusky.pond.sub.org> <20161107171111.GR5057@thinpad.lan.raisama.net> <87a8damntm.fsf@dusky.pond.sub.org> <20161111121744.GA5348@orkuz.home> Date: Fri, 11 Nov 2016 15:29:21 +0100 In-Reply-To: <20161111121744.GA5348@orkuz.home> (Jiri Denemark's message of "Fri, 11 Nov 2016 13:17:44 +0100") Message-ID: <87inruum2m.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: libvir-list@redhat.com, Igor Mammedov , qemu-devel@nongnu.org, Andreas =?utf-8?Q?F=C3=A4rber?= Jiri Denemark writes: > On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote: >> Eduardo Habkost writes: >> > libvirt wants to know if the QEMU binary supports a given -cpu >> > option (normally CPU features that can be enabled/disabled using >> > "+foo"/"-foo"). >> >> The obvious way to check whether a specific CPU supports it is to >> introspect that CPU. >> >> The obvious way to check whether all CPUs of interest support it >> (assuming that is a productive question) is to introspect all CPUs of >> interest. Works regardless of whether the option is inherited, which is >> really an implementation detail. > > As Eduardo said, libvirt wants to know whether it can use a given CPU > feature with current QEMU binary. In -cpu help, we can see a list of > models and features QEMU understands, but we need to get similar info > via QMP. CPU models are easy, but how do we get the list of CPU > features? If introspection is the way to get it, I'm fine with that, > just beware that we don't actually know the name of the CPU object > (Westmere-x86_64-cpu), we only know the name of the CPU model > (Westmere). Actually, you do: { "execute": "qom-list-types", "arguments": { "implements": "cpu" } } {"return": [{"name": "Westmere-x86_64-cpu"}, ...]} > So if the object name is needed, we need to query the > mapping from CPU model names to CPU object names. Hmm. The problem is that some interfaces such as -cpu require a "CPU model name", but introspection gives you the QOM type name. The mapping from "model name" to type name even depends on the target: it's CPUClass method class_by_name(). Can't say I like that, but we got to play the hand we were dealt, and that means we need to provide a way to introspect the mapping between CPU model name and QOM type name. Eduardo's plan to add the QOM type name to query-cpu-definitions makes more sense to me now.