From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7mpw-0003v8-7g for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:43:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7mpu-00076t-78 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:43:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42033 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7mpt-00076d-Ro for qemu-devel@nongnu.org; Wed, 24 Jun 2015 11:43:38 -0400 Message-ID: <558AD028.6000607@suse.de> Date: Wed, 24 Jun 2015 17:43:36 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20150623173048-mutt-send-email-mst@redhat.com> <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> <20150623231818-mutt-send-email-mst@redhat.com> <20150624141651.GS3134@thinpad.lan.raisama.net> <20150624161820-mutt-send-email-mst@redhat.com> <558AC021.1080403@suse.de> <20150624165140-mutt-send-email-mst@redhat.com> In-Reply-To: <20150624165140-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [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: "Michael S. Tsirkin" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Eduardo Habkost Am 24.06.2015 um 16:57 schrieb Michael S. Tsirkin: > On Wed, Jun 24, 2015 at 04:35:13PM +0200, Andreas F=E4rber wrote: >> Am 24.06.2015 um 16:19 schrieb Michael S. Tsirkin: >>> On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote: >>>>> IMHO -M pc is not supposed to mean "can break at any time". >>>> >>>> It means "it may have new host-side requirements and may become runn= able >>>> in your host (or require additional command-line flags to run) at an= y time". >>> >>> That would be pretty bad. I don't think we ever had such cases in pra= ctice. >> >> Why is that bad or unexpected? If you install new software, it may hav= e >> new dependencies. QEMU would be no different from other software there= . >=20 > That's just basic compatibility. If I run using same flags, I expect > compatible behaviour. >=20 > How would you like it if each time you update bash, all your scripts ha= d > to stop working, unless you specify a specific compability flag in > scripts, in which case you miss (some) bugfixes? >=20 > Or if you found code snippets and they can't both work. Why? Because > snippet 1 says request version 2.4 compatibility and another says use v= ersion 2.5 > compatibility, so you can't use both. >=20 > Each time you break command line compatibility, you > invalidate an unknown chunk of useful documentation somewhere. Not sure if we're talking about the same thing. For starters, bash or qemu-system-foo may have a dependency on a new library. sudo recently grew dependencies on some auditing syscall. Certain machine or CPU level KVM features may require new ioctls. Therefore new features may have new dependencies, and by default when not in backwards-compatibility mode we want to enable such new features and not just some ancient frozen subset - which would be comparable to Solaris' /bin/sh being a really ancient version with new ones under new names. Don't understand what you mean with those two snippets. Either way it seems a fundamental non-issue at the moment. qemu64 apart from x2apic did not change much. I certainly didn't propose any functional feature changes myself and only took patches once okayed from KVM and x86 reviewers, raising the compat_props card. However, looking beyond the artificial qemu64, a causal problem beneath this discussion seems to be our white-listing of CPU features rather than transparently black-listing all but implemented features. Apart from omission bugs, there's two ways CPU features can get added, implementation in TCG and kernel support in KVM. Only the KVM support depends on the host, whereas the TCG support solely depends on the QEMU version. Bug fixes would not fall into the implementation-dependent category. And for the feature-moratorium Paolo proposed I wonder whether we have any mechanism to assure and test that? 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)