From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFP6e-0001Ri-Sp for qemu-devel@nongnu.org; Tue, 21 Jun 2016 13:04:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFP6Y-00030L-SS for qemu-devel@nongnu.org; Tue, 21 Jun 2016 13:04:55 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:30544 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFP6Y-00030G-ND for qemu-devel@nongnu.org; Tue, 21 Jun 2016 13:04:50 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5LH4XAM128156 for ; Tue, 21 Jun 2016 13:04:49 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 23q9nag19e-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Jun 2016 13:04:49 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Jun 2016 18:04:47 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id CE77F17D805A for ; Tue, 21 Jun 2016 18:06:01 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5LH4jCj9306602 for ; Tue, 21 Jun 2016 17:04:45 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u5LH4j1J023146 for ; Tue, 21 Jun 2016 13:04:45 -0400 Date: Tue, 21 Jun 2016 19:04:43 +0200 From: David Hildenbrand In-Reply-To: <20160621161538.GH2048@thinpad.lan.raisama.net> References: <1466453564-7572-1-git-send-email-ehabkost@redhat.com> <20160621082040.57c15988@thinkpad-w530> <20160621124542.GF2048@thinpad.lan.raisama.net> <20160621145254.7c982019@thinkpad-w530> <20160621161538.GH2048@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20160621190443.5530f3f1@thinkpad-w530> Subject: Re: [Qemu-devel] [PATCH 0/3] qmp: query-host-cpu command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, Jiri Denemark , libvir-list@redhat.com, Igor Mammedov > On Tue, Jun 21, 2016 at 02:52:54PM +0200, David Hildenbrand wrote: > > > On Tue, Jun 21, 2016 at 08:20:40AM +0200, David Hildenbrand wrote: > > > > > Add QMP command to allow management software to query for > > > > > CPU information for the running host. > > > > > > > > > > The data returned by the command is in the form of a dictionary > > > > > of QOM properties. > > > > > > > > > > This series depends on the "Add runnability info to > > > > > query-cpu-definitions" series I sent 2 weeks ago. > > > > > > > > > > Git tree: > > > > > https://github.com/ehabkost/qemu-hacks.git work/query-host-cpu > > > > > > > > > > > > > I like that interface, I'm going to post (maybe today? :) ) a similar interface > > > > that allows to also expand other cpu models, not just the host model. > > > > > > In x86 I want to avoid exposing the details of other CPU models > > > to libvirt because the details depend on machine-type. > > > > > > But if it is useful for you, I believe the same "qom-properties" > > > dict could be returned in query-cpu-definitions. > > > > > > > > > > > Maybe we can then decide which one makes sense for all of us. But in general, > > > > this interface is much better compared to what we had before. > > > > > > Maybe both? I think it's better to have a separate interface for > > > querying "what exactly this host supports" and another one for > > > querying for "what happens if I use -cpu host". In the case of > > > x86, both are equivalent, but we can't guarantee this on all > > > architectures. > > > > > > > I'll post my patches in a couple of minutes, let's discuss it > > then. > > > > We might want to avoid having multiple interfaces carrying out > > the same task. > > OK, I will wait for the patches before discussing it. My > assumption is that both look similar, but are actually different > tasks. > For us, also "-cpu host" and querying the host model is identical. Not sure if there would for now really be a requirement for some other architecture to handle this differently. Do you have anything specific already in mind? But let's see if it indeed makes sense to split this up after looking at our interface proposal. David