linux-kernel - Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Apr 2015 09:09:07 +0200
From:	Michael Mueller <mimu@...ux.vnet.ibm.com>
To:	Eduardo Habkost <ehabkost@...hat.com>
Cc:	linux-s390@...r.kernel.org,
	Cornelia Huck <cornelia.huck@...ibm.com>, kvm@...r.kernel.org,
	Gleb Natapov <gleb@...nel.org>, qemu-devel@...gnu.org,
	linux-kernel@...r.kernel.org, libvir-list@...hat.com,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Alexander Graf <agraf@...e.de>,
	"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
	Daniel Hansel <daniel.hansel@...ux.vnet.ibm.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Jiri Denemark <jdenemar@...hat.com>,
	Andreas Faerber <afaerber@...e.de>,
	Richard Henderson <rth@...ddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command
 query-cpu-model

On Wed, 1 Apr 2015 20:05:24 -0300
Eduardo Habkost <ehabkost@...hat.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.

> 
> 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": <alias>, "runnable": <true|false>, "stable-abi-save":
false } in the s390 case, right?

Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/