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] [day] [month] [year] [list]

Message-ID: <20150402151538.GO7031@thinpad.lan.raisama.net>
Date:	Thu, 2 Apr 2015 12:15:38 -0300
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	Michael Mueller <mimu@...ux.vnet.ibm.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 Thu, Apr 02, 2015 at 09:09:07AM +0200, Michael Mueller wrote:
> 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.

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