From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n4B-0002VO-To for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:58:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7n47-00062c-V9 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:58:23 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42872 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n47-00061t-N0 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:58:19 -0400 Message-ID: <558AD39A.1070607@suse.de> Date: Wed, 24 Jun 2015 17:58:18 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> <55898D94.4070702@suse.de> <20150623171122.GI3134@thinpad.lan.raisama.net> <20150623213445.GA17756@redhat.com> <20150624142446.GU3134@thinpad.lan.raisama.net> <20150624162659-mutt-send-email-mst@redhat.com> <20150624154429.GW3134@thinpad.lan.raisama.net> In-Reply-To: <20150624154429.GW3134@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Not introducing new host-side requirements on new machine-type versions (was Re: [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net Am 24.06.2015 um 17:44 schrieb Eduardo Habkost: > In another message, Paolo wrote: >> libvirt should trust that QEMU developers will not prevent a VM from >> running on a previously viable host, just because you change the machi= ne >> type. >=20 > I assumed that was never going to be true. >=20 > As long as QEMU guarantees that, so we don't change existing CPU models > (in new machines) in a way that introduces new host-side dependencies, > we will be OK. >=20 > We may need something new to implement this guarantee for KVM features, > though. libvirt will need something that says "please don't enable any > KVM CPUID bits silently for me, let me ask for them explicitly". But > that won't be as drastic as requiring "-cpu custom". That's what I suggested a global property for yesterday. Not sure how it would be implemented though. > That have some consequences in the way we add new CPU models and > implement CPU model changes. For example: until we know all the feature= s > we want in a CPU model are already available and supported in the lates= t > kernel, we won't add a new CPU model. The choice of features in CPU > models should be "final" as soon as we add the CPU model, so CPU model > changes should never introduce new host-side requirements. If a CPU > model change requires some additional KVM code or newer host CPU, we > need to add a new CPU model name. We must agree on that and document it= , > because I expect to see some complaints in the future when enforcing > this rule. >=20 >> >> It's as if someone wrote a wrapper around all kernel system calls >> on the assumption that kernel can not guarantee kernel/userspace ABI >> will never change. It can and it does. >> >> So let's promise not to break things, and avoid a ton of copy and past= e bugs. >=20 > My assumption was that this (introducing type-(2) machine changes) was > never considered "breaking things" and just a fact of life. >=20 > If we guarantee that we will never prevent a VM from running on a > previously viable host, just because you change the machine type, we > will be OK. Could you clarify whether that is for KVM only or in general? Also, if we ignore qemu64 and pick a current X86CPU such as Haswell, can you make a list of features that are missing in our model and in KVM, if any, and might be enabled in future Haswell / Haswell+X models? What delta are we talking about exactly? Are we at the same point of stability guarantee for ppc POWER? For s390x, arm and aarch64 I guess not yet? Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)