From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5Xfv-0004ed-UT for qemu-devel@nongnu.org; Fri, 20 Oct 2017 09:49:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5Xfr-0008AT-28 for qemu-devel@nongnu.org; Fri, 20 Oct 2017 09:49:24 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:38218 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e5Xfq-0008A8-SF for qemu-devel@nongnu.org; Fri, 20 Oct 2017 09:49:18 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9KDnFn6127392 for ; Fri, 20 Oct 2017 09:49:15 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2dqja2g6t1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Oct 2017 09:49:15 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Oct 2017 14:49:07 +0100 References: <87y3oqugm7.fsf@marc-ibm.boeblingen.de.ibm.com> <20171005121115.GD3946746@orkuz.home> <87y3ok7n2n.fsf@marc-ibm.boeblingen.de.ibm.com> <20171012120714.GA314661@orkuz.home> <87mv4m6pp5.fsf@marc-ibm.boeblingen.de.ibm.com> <0aab6dae-a926-c106-9bc5-68561a9bef5c@redhat.com> <0dae2b6c-9164-efc7-5c67-0e4aa5eb4a21@de.ibm.com> From: Christian Borntraeger Date: Fri, 20 Oct 2017 15:49:04 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: <2bfd5f45-3db1-b6c7-3162-43be564cfa05@de.ibm.com> Subject: Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand , Marc Hartmayer , libvir-list@redhat.com, qemu-devel@nongnu.org Cc: Jiri Denemark , Boris Fiuczynski , "Jason J. Herne" , Viktor Mihajlovski On 10/20/2017 03:43 PM, David Hildenbrand wrote: > On 20.10.2017 15:36, Christian Borntraeger wrote: >> >> >> On 10/20/2017 03:16 PM, David Hildenbrand wrote: >>> >>>> Hi all, >>>> >>>> we recently encountered the problem that the 'host-model' [1] has to be >>>> related to the machine type of a domain. We have following problem: >>>> >>>> Let's assume we've a z13 system with a QEMU 2.9 and we define a >>>> domain using the default s390-virtio-ccw machine together with the >>>> host-model CPU mode [1]. The definition will have the machine >>>> expanded to s390-virtio-ccw-2.9 but retain the host-model CPU mode >>>> in the domain definition. In a next step we upgrade to QEMU 2.10 >>>> (first version to recognize z14). Everything is still fine, even >>>> though the machine runs in 2.9 compatibility mode. Finally we >>>> upgrade to a z14. As a consequence it is not possible to start the >>>> domain anymore as the machine type doesn't support our CPU host >>>> model (which is expanded at start time of the domain). >>> >>> Actually, what is the cause of that problem? I assume it is the gs >>> feature (gs_allowed)? >>> >>> We should really avoid such things (..._allowed) for CPU model features >>> in the future and clue all new such stuff to cpumodel_allowed. >> >> Yes, starting a guest with >> >> hvm >> >> >> >> results in >> >> qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: gs >> >> Tying it to cpumodel_allowed would not help, migration-wise though. >> libvirt would still transform >> >> >> hvm >> >> > > My point was, that the host model would have to be copied and _remain_ > there when s390-ccw-virtio was expanded to s390-ccw-virtio-2.9. > > So really replacing by the model z13-base.... > This would at least fix this issue. Just like s390-ccw-virtio get's > replaced and remains thats way. > > But this might for sure have other problems. The problem goes much further. A fresh guest with hvm does not start. No migration from an older system is necessary.