Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

["Andreas Färber" <afaerber@suse.de>]

Am 24.06.2015 um 16:57 schrieb Michael S. Tsirkin:
> On Wed, Jun 24, 2015 at 04:35:13PM +0200, Andreas Färber 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 runnable
>>>> in your host (or require additional command-line flags to run) at any time".
>>>
>>> That would be pretty bad. I don't think we ever had such cases in practice.
>>
>> Why is that bad or unexpected? If you install new software, it may have
>> new dependencies. QEMU would be no different from other software there.
> 
> That's just basic compatibility.  If I run using same flags, I expect
> compatible behaviour.
> 
> How would you like it if each time you update bash, all your scripts had
> to stop working, unless you specify a specific compability flag in
> scripts, in which case you miss (some) bugfixes?
> 
> 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 version 2.5
> compatibility, so you can't use both.
> 
> 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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)