linux-kernel - Re: [Qemu-devel] [PATCH v5 00/17] s390x cpu model implementation

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:	Mon, 27 Apr 2015 10:11:50 +0200
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	Michael Mueller <mimu@...ux.vnet.ibm.com>, qemu-devel@...gnu.org,
	kvm@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-kernel@...r.kernel.org
CC:	Eduardo Habkost <ehabkost@...hat.com>,
	Gleb Natapov <gleb@...nel.org>, Alexander Graf <agraf@...e.de>,
	Daniel Hansel <daniel.hansel@...ux.vnet.ibm.com>,
	"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Richard Henderson <rth@...ddle.net>,
	Andreas Faerber <afaerber@...e.de>
Subject: Re: [Qemu-devel] [PATCH v5 00/17] s390x cpu model implementation

Am 13.04.2015 um 15:56 schrieb Michael Mueller:
> This patch set in combination with its kernel kvm patch set proposes an
> implementation of S390 CPU models. The origin of this item is to provide
> a means for management interfaces like libvirt to draw decisions if life
> guest migration to a target hypervisor is reasonable.
> 
> A migration constraint is that a target hypervisor is capable to run a
> guest with the same CPU model as the source hypervisor does. To
> verify this condition, the administration interface employes the existing
> QMP command "query-cpu-definitions" which returns a list of all currently
> supported CPU models of a given host system. Together with the extension of
> QMP command "query-cpus", the current CPU model of a guest is retrievable
> and a conclusion can be drawn if a migration is possible.
> 
> A S390 CPU model is defined as a triple of machine type, CPU facility set
> and IBC value. Each historic, current and future triple receives a name
> composed of the machine type and its general availability counter. This name
> forms the CPU model name (e.g.: "2817-ga2".)
> 
> With means of the Instruction Blocking Control feature (IBC), the instruction
> set available to a given guest is limitable.

>From an s390 perspective this series looks like the right approach. When looking
closer things are slightly more complicated than expected:

The base line is the CPU type (like 2964 aka z13). This also qualifies the
type of the whole guest (its not a cpu but a system property). This can be
queried in the guest with the STIPD(store cpu id) instruction.

Then there a the guest visible facilities. Those are the common subset of
the facilities provides by the machine, LPAR and potentially z/VM. We can then
add the facilities that are fully handled by QEMU. In theory this can be
up to 16k facility bits and can be queried in the guest with the STFLE(store
facility list extended) instruction.

It is the responsibility of QEMU/KVM to follow the facility bits when doing
an instruction handling. For things handled by the HW we have to setup the 
IBC control to be as good as possible.

This series seem to handle all cases as far as I can see during test and review.

Christian

As long as the libvirt ans x86 folks are fine with the interfaces on the QMP
level I think this is almost good to go.

I have some minor style things as followup. With that fixed
Acked-by: Christian Borntraeger <borntraeger@...ibm.com>
for the series.

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