From: Eduardo Habkost <ehabkost@redhat.com> To: Michael Mueller <mimu@linux.vnet.ibm.com> Cc: linux-s390@vger.kernel.org, Cornelia Huck <cornelia.huck@de.ibm.com>, kvm@vger.kernel.org, Gleb Natapov <gleb@kernel.org>, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, Christian Borntraeger <borntraeger@de.ibm.com>, Alexander Graf <agraf@suse.de>, "Jason J. Herne" <jjherne@linux.vnet.ibm.com>, Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>, Paolo Bonzini <pbonzini@redhat.com>, Jiri Denemark <jdenemar@redhat.com>, Andreas Faerber <afaerber@suse.de>, Richard Henderson <rth@twiddle.net> Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model Date: Thu, 2 Apr 2015 12:15:38 -0300 [thread overview] Message-ID: <20150402151538.GO7031@thinpad.lan.raisama.net> (raw) In-Reply-To: <20150402090907.5b44018f@bee> On Thu, Apr 02, 2015 at 09:09:07AM +0200, Michael Mueller wrote: > On Wed, 1 Apr 2015 20:05:24 -0300 > Eduardo Habkost <ehabkost@redhat.com> 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. Exactly. > > > > > 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. Yes. "stable-abi-safe" would mean that nothing guest-visible will change in the CPU model when running a different QEMU version or running in a different host, thus making it safe to live-migrate (as long as you keep the same machine+accelerator and don't change other guest-visible configuration in the QEMU command-line, of course). That's a constraint we already keep in the x86 CPU models, except for "-cpu host". In other words, it means "as long as the name matches the query-cpus output from the source host, it is guaranteed to be safe to live-migrate". Which is the constraint you need, right? (I am not 100% sure about the naming. Maybe we should call it "live-migration-safe"?) > > Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and > the aliases can be represented as { "name": <alias>, "runnable": <true|false>, "stable-abi-save": > false } in the s390 case, right? Exactly. We don't need to return them in the first version if you don't need to (althought I don't see a reason to not return them). It will just allow us to return them in the future. -- Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com> To: Michael Mueller <mimu@linux.vnet.ibm.com> Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, Christian Borntraeger <borntraeger@de.ibm.com>, Gleb Natapov <gleb@kernel.org>, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, Alexander Graf <agraf@suse.de>, Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>, "Jason J. Herne" <jjherne@linux.vnet.ibm.com>, Cornelia Huck <cornelia.huck@de.ibm.com>, Paolo Bonzini <pbonzini@redhat.com>, Jiri Denemark <jdenemar@redhat.com>, Andreas Faerber <afaerber@suse.de>, Richard Henderson <rth@twiddle.net> Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model Date: Thu, 2 Apr 2015 12:15:38 -0300 [thread overview] Message-ID: <20150402151538.GO7031@thinpad.lan.raisama.net> (raw) In-Reply-To: <20150402090907.5b44018f@bee> On Thu, Apr 02, 2015 at 09:09:07AM +0200, Michael Mueller wrote: > On Wed, 1 Apr 2015 20:05:24 -0300 > Eduardo Habkost <ehabkost@redhat.com> 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. Exactly. > > > > > 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. Yes. "stable-abi-safe" would mean that nothing guest-visible will change in the CPU model when running a different QEMU version or running in a different host, thus making it safe to live-migrate (as long as you keep the same machine+accelerator and don't change other guest-visible configuration in the QEMU command-line, of course). That's a constraint we already keep in the x86 CPU models, except for "-cpu host". In other words, it means "as long as the name matches the query-cpus output from the source host, it is guaranteed to be safe to live-migrate". Which is the constraint you need, right? (I am not 100% sure about the naming. Maybe we should call it "live-migration-safe"?) > > Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and > the aliases can be represented as { "name": <alias>, "runnable": <true|false>, "stable-abi-save": > false } in the s390 case, right? Exactly. We don't need to return them in the first version if you don't need to (althought I don't see a reason to not return them). It will just allow us to return them in the future. -- Eduardo
next prev parent reply other threads:[~2015-04-02 15:15 UTC|newest] Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-30 14:28 [PATCH v4 00/15] s390x cpu model implementation Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` [PATCH v4 01/15] Introduce stub routine cpu_desc_avail Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` [PATCH v4 02/15] target-s390x: Introduce cpu facilities Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 03/15] target-s390x: Generate facility defines per cpu model Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` [PATCH v4 04/15] target-s390x: Introduce cpu models Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 05/15] target-s390x: Define cpu model specific facility lists Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 06/15] target-s390x: Add cpu model alias definition routines Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` [PATCH v4 07/15] target-s390x: Update linux-headers/asm-s390/kvm.h Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 19:36 ` Christian Borntraeger 2015-03-30 19:36 ` [Qemu-devel] " Christian Borntraeger 2015-03-30 19:36 ` Christian Borntraeger 2015-03-31 7:25 ` Michael Mueller 2015-03-31 7:25 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` [PATCH v4 08/15] target-s390x: Add KVM VM attribute interface for cpu models Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 09/15] target-s390x: Add cpu class initialization routines Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 10/15] target-s390x: Prepare accelerator during cpu object realization Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 19:33 ` Eduardo Habkost 2015-03-30 19:33 ` [Qemu-devel] " Eduardo Habkost 2015-03-31 10:26 ` Michael Mueller 2015-03-31 10:26 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 19:50 ` Eduardo Habkost 2015-03-30 19:50 ` [Qemu-devel] " Eduardo Habkost 2015-03-31 9:10 ` Michael Mueller 2015-03-31 9:10 ` Michael Mueller 2015-03-30 20:17 ` Eduardo Habkost 2015-03-30 20:17 ` [Qemu-devel] " Eduardo Habkost 2015-03-30 20:17 ` Eduardo Habkost 2015-03-30 20:20 ` [Qemu-devel] " Eric Blake 2015-03-30 20:20 ` Eric Blake 2015-03-30 20:20 ` Eric Blake 2015-03-31 13:16 ` [Qemu-devel] " Eduardo Habkost 2015-03-31 13:16 ` Eduardo Habkost 2015-03-31 11:21 ` Michael Mueller 2015-03-31 11:21 ` Michael Mueller 2015-03-31 18:28 ` Eduardo Habkost 2015-03-31 18:28 ` Eduardo Habkost 2015-03-30 20:19 ` Eric Blake 2015-03-30 20:19 ` Eric Blake 2015-03-31 7:56 ` Michael Mueller 2015-03-31 7:56 ` Michael Mueller 2015-03-31 7:56 ` Michael Mueller 2015-03-31 18:35 ` Eduardo Habkost 2015-03-31 18:35 ` [Qemu-devel] " Eduardo Habkost 2015-03-31 20:09 ` Michael Mueller 2015-03-31 20:09 ` [Qemu-devel] " Michael Mueller 2015-03-31 20:09 ` Michael Mueller 2015-04-01 13:01 ` Eduardo Habkost 2015-04-01 13:01 ` [Qemu-devel] " Eduardo Habkost 2015-04-01 16:31 ` Michael Mueller 2015-04-01 16:31 ` Michael Mueller 2015-04-01 16:59 ` Eduardo Habkost 2015-04-01 16:59 ` Eduardo Habkost 2015-04-01 16:59 ` Eduardo Habkost 2015-04-01 19:05 ` [Qemu-devel] " Michael Mueller 2015-04-01 19:05 ` Michael Mueller 2015-04-01 19:05 ` Michael Mueller 2015-04-01 19:10 ` [Qemu-devel] " Michael Mueller 2015-04-01 19:10 ` Michael Mueller 2015-04-01 23:05 ` Eduardo Habkost 2015-04-01 23:05 ` Eduardo Habkost 2015-04-01 23:05 ` Eduardo Habkost 2015-04-02 7:09 ` [Qemu-devel] " Michael Mueller 2015-04-02 7:09 ` Michael Mueller 2015-04-02 7:09 ` Michael Mueller 2015-04-02 15:15 ` Eduardo Habkost [this message] 2015-04-02 15:15 ` [Qemu-devel] " Eduardo Habkost 2015-03-30 14:28 ` [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 20:28 ` Eric Blake 2015-03-30 20:28 ` Eric Blake 2015-03-31 7:42 ` Michael Mueller 2015-03-31 7:42 ` Michael Mueller 2015-03-31 7:42 ` Michael Mueller 2015-03-31 19:46 ` Eduardo Habkost 2015-03-31 19:46 ` [Qemu-devel] " Eduardo Habkost 2015-03-31 19:46 ` Eduardo Habkost 2015-03-31 19:50 ` Eric Blake 2015-03-31 19:50 ` [Qemu-devel] " Eric Blake 2015-03-31 19:50 ` Eric Blake 2015-03-31 20:22 ` [Qemu-devel] " Michael Mueller 2015-03-31 20:22 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 13/15] target-s390x: Extend " Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 19:54 ` Eduardo Habkost 2015-03-30 19:54 ` [Qemu-devel] " Eduardo Habkost 2015-03-30 14:28 ` [PATCH v4 14/15] target-s390x: Introduce facility test routine Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller 2015-03-30 14:28 ` Michael Mueller 2015-03-30 14:28 ` [PATCH v4 15/15] target-s390x: Enable cpu model usage Michael Mueller 2015-03-30 14:28 ` [Qemu-devel] " Michael Mueller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150402151538.GO7031@thinpad.lan.raisama.net \ --to=ehabkost@redhat.com \ --cc=afaerber@suse.de \ --cc=agraf@suse.de \ --cc=borntraeger@de.ibm.com \ --cc=cornelia.huck@de.ibm.com \ --cc=daniel.hansel@linux.vnet.ibm.com \ --cc=gleb@kernel.org \ --cc=jdenemar@redhat.com \ --cc=jjherne@linux.vnet.ibm.com \ --cc=kvm@vger.kernel.org \ --cc=libvir-list@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=mimu@linux.vnet.ibm.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rth@twiddle.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.