From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n56-0004Du-7Q for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:59:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7n55-0006TB-6N for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:59:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n55-0006SJ-23 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:59:19 -0400 Message-ID: <558AD3D1.2000807@redhat.com> Date: Wed, 24 Jun 2015 17:59:13 +0200 From: Paolo Bonzini 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 , "Michael S. Tsirkin" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Jiri Denemark , =?windows-1252?Q?Andreas_F=E4rber?= , rth@twiddle.net On 24/06/2015 17:44, Eduardo Habkost wrote: > 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". >=20 > 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 ... that require host-side support. > should be "final" as soon as we add the CPU model, so CPU model > changes should never introduce new host-side requirements. Just like we are doing for ARAT, we can always hack around the limitation in kvm_arch_get_supported_cpuid, because new features that require kernel support are overall rare. It happened for TSC_DEADLINE/RDTSCP/XSAVE (Sandy Bridge), and it will happen for MPX/XSAVES (Skylake), but that was pretty much it in the last few years. Paolo > 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.