All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Mueller <mimu@linux.vnet.ibm.com>
To: Eduardo Habkost <ehabkost@redhat.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: Wed, 1 Apr 2015 21:05:31 +0200	[thread overview]
Message-ID: <20150401210531.57d2ea98@bee> (raw)
In-Reply-To: <20150401165905.GM7031@thinpad.lan.raisama.net>

On Wed, 1 Apr 2015 13:59:05 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:

> > Not directly invalid as "-cpu none" will be the same as omitting the -cpu option.
> > KVM will setup the vcpu properties withou any QEMU control to whatever the hosting
> > machine and the kvm kernel code offers. That will allow to run QEMU against a KVM
> > version that is not aware of the s390 cpu model ioctls.  
> 
> It looks like we have conflicting expectations about
> query-cpu-definitions, it seems: on the one hand, if "-cpu none" is
> valid I believe it should appear on the query-cpu-definitions return
> value; on the other hand, it is not (always?) migration-safe, so just
> comparing the source query-cpus data with the target
> query-cpu-definitions data wouldn't be enough to ensure live-migration
> safety.

There are other cases as well where the value given with -cpu is *not* part
of the cpu definition list and that is aliases:

[mimu@p57lp59 (master-cpu-model) qemu]$ ./s390x-softmmu/qemu-system-s390x -machine
s390-ccw,accel=kvm -cpu ?
s390 2064-ga1   IBM zSeries 900 GA1
s390 2064-ga2   IBM zSeries 900 GA2
s390 2064-ga3   IBM zSeries 900 GA3
s390 2064       (alias for 2064-ga3)
s390 z900       (alias for 2064-ga3)
...
s390 z10        (alias for 2097-ga3)
s390 z10-ec     (alias for 2097-ga3)
s390 2098-ga1   IBM System z10 BC GA1
s390 2098-ga2   IBM System z10 BC GA2
s390 2098       (alias for 2098-ga2)
s390 z10-bc     (alias for 2098-ga2)
s390 2817-ga1   IBM zEnterprise 196 GA1
s390 2817-ga2   IBM zEnterprise 196 GA2
s390 2817       (alias for 2817-ga2)
s390 z196       (alias for 2817-ga2)
s390 2818-ga1   IBM zEnterprise 114 GA1
s390 2818       (alias for 2818-ga1)
s390 z114       (alias for 2818-ga1)
s390 2827-ga1   IBM zEnterprise EC12 GA1
s390 2827-ga2   IBM zEnterprise EC12 GA2
s390 2827       (alias for 2827-ga2)
s390 zEC12      (alias for 2827-ga2)
s390 host       (alias for 2827-ga2)
s390 2828-ga1   IBM zEnterprise BC12 GA1
s390 2828       (alias for 2828-ga1)
s390 zBC12      (alias for 2828-ga1)

As you can see "host" is in s390x case always an alias and also all other aliases
are normalized to their real cpu models in the cpu-definitions list.

> 
> On x86, we have a similar problem with "-cpu host", that changes
> depending on the host hardware and host kernel. We solve this problem by
> making libvirt code aware of the set of valid CPU models, and libvirt
> has special cases for "-cpu host".

"-cpu host" is not a special case for s390, it will return ("2827-ga2", "kvm") as
cpu model or whatever model the hosting system implements.

> 
> 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...

Michael


WARNING: multiple messages have this Message-ID (diff)
From: Michael Mueller <mimu@linux.vnet.ibm.com>
To: Eduardo Habkost <ehabkost@redhat.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: [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
Date: Wed, 1 Apr 2015 21:05:31 +0200	[thread overview]
Message-ID: <20150401210531.57d2ea98@bee> (raw)
In-Reply-To: <20150401165905.GM7031@thinpad.lan.raisama.net>

On Wed, 1 Apr 2015 13:59:05 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:

> > Not directly invalid as "-cpu none" will be the same as omitting the -cpu option.
> > KVM will setup the vcpu properties withou any QEMU control to whatever the hosting
> > machine and the kvm kernel code offers. That will allow to run QEMU against a KVM
> > version that is not aware of the s390 cpu model ioctls.  
> 
> It looks like we have conflicting expectations about
> query-cpu-definitions, it seems: on the one hand, if "-cpu none" is
> valid I believe it should appear on the query-cpu-definitions return
> value; on the other hand, it is not (always?) migration-safe, so just
> comparing the source query-cpus data with the target
> query-cpu-definitions data wouldn't be enough to ensure live-migration
> safety.

There are other cases as well where the value given with -cpu is *not* part
of the cpu definition list and that is aliases:

[mimu@p57lp59 (master-cpu-model) qemu]$ ./s390x-softmmu/qemu-system-s390x -machine
s390-ccw,accel=kvm -cpu ?
s390 2064-ga1   IBM zSeries 900 GA1
s390 2064-ga2   IBM zSeries 900 GA2
s390 2064-ga3   IBM zSeries 900 GA3
s390 2064       (alias for 2064-ga3)
s390 z900       (alias for 2064-ga3)
...
s390 z10        (alias for 2097-ga3)
s390 z10-ec     (alias for 2097-ga3)
s390 2098-ga1   IBM System z10 BC GA1
s390 2098-ga2   IBM System z10 BC GA2
s390 2098       (alias for 2098-ga2)
s390 z10-bc     (alias for 2098-ga2)
s390 2817-ga1   IBM zEnterprise 196 GA1
s390 2817-ga2   IBM zEnterprise 196 GA2
s390 2817       (alias for 2817-ga2)
s390 z196       (alias for 2817-ga2)
s390 2818-ga1   IBM zEnterprise 114 GA1
s390 2818       (alias for 2818-ga1)
s390 z114       (alias for 2818-ga1)
s390 2827-ga1   IBM zEnterprise EC12 GA1
s390 2827-ga2   IBM zEnterprise EC12 GA2
s390 2827       (alias for 2827-ga2)
s390 zEC12      (alias for 2827-ga2)
s390 host       (alias for 2827-ga2)
s390 2828-ga1   IBM zEnterprise BC12 GA1
s390 2828       (alias for 2828-ga1)
s390 zBC12      (alias for 2828-ga1)

As you can see "host" is in s390x case always an alias and also all other aliases
are normalized to their real cpu models in the cpu-definitions list.

> 
> On x86, we have a similar problem with "-cpu host", that changes
> depending on the host hardware and host kernel. We solve this problem by
> making libvirt code aware of the set of valid CPU models, and libvirt
> has special cases for "-cpu host".

"-cpu host" is not a special case for s390, it will return ("2827-ga2", "kvm") as
cpu model or whatever model the hosting system implements.

> 
> 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...

Michael

WARNING: multiple messages have this Message-ID (diff)
From: Michael Mueller <mimu@linux.vnet.ibm.com>
To: Eduardo Habkost <ehabkost@redhat.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: Wed, 1 Apr 2015 21:05:31 +0200	[thread overview]
Message-ID: <20150401210531.57d2ea98@bee> (raw)
In-Reply-To: <20150401165905.GM7031@thinpad.lan.raisama.net>

On Wed, 1 Apr 2015 13:59:05 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:

> > Not directly invalid as "-cpu none" will be the same as omitting the -cpu option.
> > KVM will setup the vcpu properties withou any QEMU control to whatever the hosting
> > machine and the kvm kernel code offers. That will allow to run QEMU against a KVM
> > version that is not aware of the s390 cpu model ioctls.  
> 
> It looks like we have conflicting expectations about
> query-cpu-definitions, it seems: on the one hand, if "-cpu none" is
> valid I believe it should appear on the query-cpu-definitions return
> value; on the other hand, it is not (always?) migration-safe, so just
> comparing the source query-cpus data with the target
> query-cpu-definitions data wouldn't be enough to ensure live-migration
> safety.

There are other cases as well where the value given with -cpu is *not* part
of the cpu definition list and that is aliases:

[mimu@p57lp59 (master-cpu-model) qemu]$ ./s390x-softmmu/qemu-system-s390x -machine
s390-ccw,accel=kvm -cpu ?
s390 2064-ga1   IBM zSeries 900 GA1
s390 2064-ga2   IBM zSeries 900 GA2
s390 2064-ga3   IBM zSeries 900 GA3
s390 2064       (alias for 2064-ga3)
s390 z900       (alias for 2064-ga3)
...
s390 z10        (alias for 2097-ga3)
s390 z10-ec     (alias for 2097-ga3)
s390 2098-ga1   IBM System z10 BC GA1
s390 2098-ga2   IBM System z10 BC GA2
s390 2098       (alias for 2098-ga2)
s390 z10-bc     (alias for 2098-ga2)
s390 2817-ga1   IBM zEnterprise 196 GA1
s390 2817-ga2   IBM zEnterprise 196 GA2
s390 2817       (alias for 2817-ga2)
s390 z196       (alias for 2817-ga2)
s390 2818-ga1   IBM zEnterprise 114 GA1
s390 2818       (alias for 2818-ga1)
s390 z114       (alias for 2818-ga1)
s390 2827-ga1   IBM zEnterprise EC12 GA1
s390 2827-ga2   IBM zEnterprise EC12 GA2
s390 2827       (alias for 2827-ga2)
s390 zEC12      (alias for 2827-ga2)
s390 host       (alias for 2827-ga2)
s390 2828-ga1   IBM zEnterprise BC12 GA1
s390 2828       (alias for 2828-ga1)
s390 zBC12      (alias for 2828-ga1)

As you can see "host" is in s390x case always an alias and also all other aliases
are normalized to their real cpu models in the cpu-definitions list.

> 
> On x86, we have a similar problem with "-cpu host", that changes
> depending on the host hardware and host kernel. We solve this problem by
> making libvirt code aware of the set of valid CPU models, and libvirt
> has special cases for "-cpu host".

"-cpu host" is not a special case for s390, it will return ("2827-ga2", "kvm") as
cpu model or whatever model the hosting system implements.

> 
> 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...

Michael

  reply	other threads:[~2015-04-01 19:05 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             ` Michael Mueller [this message]
2015-04-01 19:05               ` [Qemu-devel] " 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                   ` [Qemu-devel] " Eduardo Habkost
2015-04-02 15:15                     ` 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=20150401210531.57d2ea98@bee \
    --to=mimu@linux.vnet.ibm.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=ehabkost@redhat.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=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: link
Be 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.