From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yme91-00067Q-IJ for qemu-devel@nongnu.org; Mon, 27 Apr 2015 04:12:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yme8y-000681-A9 for qemu-devel@nongnu.org; Mon, 27 Apr 2015 04:11:59 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:48974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yme8y-00067v-1d for qemu-devel@nongnu.org; Mon, 27 Apr 2015 04:11:56 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Apr 2015 09:11:55 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id C0A2C1B08061 for ; Mon, 27 Apr 2015 09:12:31 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3R8BrgK5439950 for ; Mon, 27 Apr 2015 08:11:53 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3R8BpQC011182 for ; Mon, 27 Apr 2015 02:11:52 -0600 Message-ID: <553DEF46.2030902@de.ibm.com> Date: Mon, 27 Apr 2015 10:11:50 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1428933396-37887-1-git-send-email-mimu@linux.vnet.ibm.com> In-Reply-To: <1428933396-37887-1-git-send-email-mimu@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/17] s390x cpu model implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Mueller , qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Eduardo Habkost , Gleb Natapov , Alexander Graf , Cornelia Huck , "Jason J. Herne" , Daniel Hansel , Paolo Bonzini , Andreas Faerber , Richard Henderson 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 for the series.