From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752505AbbDBHJW (ORCPT ); Thu, 2 Apr 2015 03:09:22 -0400 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:50984 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485AbbDBHJS (ORCPT ); Thu, 2 Apr 2015 03:09:18 -0400 Date: Thu, 2 Apr 2015 09:09:07 +0200 From: Michael Mueller To: Eduardo Habkost Cc: linux-s390@vger.kernel.org, Cornelia Huck , kvm@vger.kernel.org, Gleb Natapov , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, Christian Borntraeger , Alexander Graf , "Jason J. Herne" , Daniel Hansel , Paolo Bonzini , Jiri Denemark , Andreas Faerber , Richard Henderson Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model Message-ID: <20150402090907.5b44018f@bee> In-Reply-To: <20150401230524.GN7031@thinpad.lan.raisama.net> References: <1427725708-52100-1-git-send-email-mimu@linux.vnet.ibm.com> <1427725708-52100-12-git-send-email-mimu@linux.vnet.ibm.com> <20150331183526.GJ7031@thinpad.lan.raisama.net> <20150331220909.4410e8c0@bee> <20150401130113.GL7031@thinpad.lan.raisama.net> <20150401183123.7a1f9d6c@bee> <20150401165905.GM7031@thinpad.lan.raisama.net> <20150401210531.57d2ea98@bee> <20150401230524.GN7031@thinpad.lan.raisama.net> Organization: IBM X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15040207-0025-0000-0000-000004908254 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 Apr 2015 20:05:24 -0300 Eduardo Habkost wrote: > > > > > > If you don't want to encode that knowledge in libvirt or other > > > management software for s390, it looks like you need something like a > > > "stable-abi-safe" field on CpuDefinitionInfo? > > > > Exactly that fulfills the "name" field for s390 already in my view. > > > > And cpu model "none" just means that QEMU does not manage the cpu model. That's also > > the reason why I initially returned an empty "[]" model and not "none". This somewhat > > convinces me to go back to this approach... > > I understand the reasons for your approach and it seems to work for > s390, but the only problem I see is that you are adding an additional > (undocumented?) s390-specific constraint to the semantics of > query-cpu-models: that the model name will appear on the list only if it > can be safely migratable. This may prevent us from unifying CPU model > code into generic code later. I agree that an aliases is something different compared with the CPU model none as there is a CPU class representing it. And thus, when implicitly or explicitly selected, shall be presented in the CPU definition list as well. If I would set "runnable" to false as it now (bad), it would be sorted out by the "considered for migration" test but it would be misleading as it is always runnable. Though an additional field like "migrate-able" could express that characteristic. > > But if we add a simple stable-abi-safe field to the list (even if s390 > set it to to true for all models and omit aliases and "none" in this > first version), we will have clearer semantics that can still be > honoured by other architectures (and by generic code) later. To be honest I currently don't right get the idea that you follow with that stable-abi-save field... But eventually yes (I wrote this before the section above) The stable-abi-save field means: "Take me into account for whatever kind of CPU model related comparison you perform between two running QEMU instances as I represent a well defined aspect. Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and the aliases can be represented as { "name": , "runnable": , "stable-abi-save": false } in the s390 case, right? Michael From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Mueller Subject: Re: [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model Date: Thu, 2 Apr 2015 09:09:07 +0200 Message-ID: <20150402090907.5b44018f@bee> References: <1427725708-52100-1-git-send-email-mimu@linux.vnet.ibm.com> <1427725708-52100-12-git-send-email-mimu@linux.vnet.ibm.com> <20150331183526.GJ7031@thinpad.lan.raisama.net> <20150331220909.4410e8c0@bee> <20150401130113.GL7031@thinpad.lan.raisama.net> <20150401183123.7a1f9d6c@bee> <20150401165905.GM7031@thinpad.lan.raisama.net> <20150401210531.57d2ea98@bee> <20150401230524.GN7031@thinpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150401230524.GN7031@thinpad.lan.raisama.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Archive: List-Post: To: Eduardo Habkost Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, Christian Borntraeger , Gleb Natapov , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, Alexander Graf , Daniel Hansel , "Jason J. Herne" , Cornelia Huck , Paolo Bonzini , Jiri Denemark , Andreas Faerber , Richard Henderson List-ID: On Wed, 1 Apr 2015 20:05:24 -0300 Eduardo Habkost wrote: > > > > > > If you don't want to encode that knowledge in libvirt or other > > > management software for s390, it looks like you need something like a > > > "stable-abi-safe" field on CpuDefinitionInfo? > > > > Exactly that fulfills the "name" field for s390 already in my view. > > > > And cpu model "none" just means that QEMU does not manage the cpu model. That's also > > the reason why I initially returned an empty "[]" model and not "none". This somewhat > > convinces me to go back to this approach... > > I understand the reasons for your approach and it seems to work for > s390, but the only problem I see is that you are adding an additional > (undocumented?) s390-specific constraint to the semantics of > query-cpu-models: that the model name will appear on the list only if it > can be safely migratable. This may prevent us from unifying CPU model > code into generic code later. I agree that an aliases is something different compared with the CPU model none as there is a CPU class representing it. And thus, when implicitly or explicitly selected, shall be presented in the CPU definition list as well. If I would set "runnable" to false as it now (bad), it would be sorted out by the "considered for migration" test but it would be misleading as it is always runnable. Though an additional field like "migrate-able" could express that characteristic. > > But if we add a simple stable-abi-safe field to the list (even if s390 > set it to to true for all models and omit aliases and "none" in this > first version), we will have clearer semantics that can still be > honoured by other architectures (and by generic code) later. To be honest I currently don't right get the idea that you follow with that stable-abi-save field... But eventually yes (I wrote this before the section above) The stable-abi-save field means: "Take me into account for whatever kind of CPU model related comparison you perform between two running QEMU instances as I represent a well defined aspect. Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and the aliases can be represented as { "name": , "runnable": , "stable-abi-save": false } in the s390 case, right? Michael From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdZFm-0002l9-6i for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:09:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdZFg-0002cd-73 for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:09:26 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:54525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdZFf-0002bl-U6 for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:09:20 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 2 Apr 2015 08:09:15 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9C62E17D8062 for ; Thu, 2 Apr 2015 08:09:42 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3279BOJ2621752 for ; Thu, 2 Apr 2015 07:09:11 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3279AV7017424 for ; Thu, 2 Apr 2015 01:09:11 -0600 Date: Thu, 2 Apr 2015 09:09:07 +0200 From: Michael Mueller Message-ID: <20150402090907.5b44018f@bee> In-Reply-To: <20150401230524.GN7031@thinpad.lan.raisama.net> References: <1427725708-52100-1-git-send-email-mimu@linux.vnet.ibm.com> <1427725708-52100-12-git-send-email-mimu@linux.vnet.ibm.com> <20150331183526.GJ7031@thinpad.lan.raisama.net> <20150331220909.4410e8c0@bee> <20150401130113.GL7031@thinpad.lan.raisama.net> <20150401183123.7a1f9d6c@bee> <20150401165905.GM7031@thinpad.lan.raisama.net> <20150401210531.57d2ea98@bee> <20150401230524.GN7031@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, Christian Borntraeger , Gleb Natapov , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, Alexander Graf , Daniel Hansel , "Jason J. Herne" , Cornelia Huck , Paolo Bonzini , Jiri Denemark , Andreas Faerber , Richard Henderson On Wed, 1 Apr 2015 20:05:24 -0300 Eduardo Habkost wrote: > > > > > > If you don't want to encode that knowledge in libvirt or other > > > management software for s390, it looks like you need something like a > > > "stable-abi-safe" field on CpuDefinitionInfo? > > > > Exactly that fulfills the "name" field for s390 already in my view. > > > > And cpu model "none" just means that QEMU does not manage the cpu model. That's also > > the reason why I initially returned an empty "[]" model and not "none". This somewhat > > convinces me to go back to this approach... > > I understand the reasons for your approach and it seems to work for > s390, but the only problem I see is that you are adding an additional > (undocumented?) s390-specific constraint to the semantics of > query-cpu-models: that the model name will appear on the list only if it > can be safely migratable. This may prevent us from unifying CPU model > code into generic code later. I agree that an aliases is something different compared with the CPU model none as there is a CPU class representing it. And thus, when implicitly or explicitly selected, shall be presented in the CPU definition list as well. If I would set "runnable" to false as it now (bad), it would be sorted out by the "considered for migration" test but it would be misleading as it is always runnable. Though an additional field like "migrate-able" could express that characteristic. > > But if we add a simple stable-abi-safe field to the list (even if s390 > set it to to true for all models and omit aliases and "none" in this > first version), we will have clearer semantics that can still be > honoured by other architectures (and by generic code) later. To be honest I currently don't right get the idea that you follow with that stable-abi-save field... But eventually yes (I wrote this before the section above) The stable-abi-save field means: "Take me into account for whatever kind of CPU model related comparison you perform between two running QEMU instances as I represent a well defined aspect. Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and the aliases can be represented as { "name": , "runnable": , "stable-abi-save": false } in the s390 case, right? Michael