Re: [Qemu-devel] [PATCH 4/6] i386: Infrastructure for versioned CPU models

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 4/6] i386: Infrastructure for versioned CPU models
Date: Tue, 25 Jun 2019 17:26:03 +0100	[thread overview]
Message-ID: <20190625162603.GK3139@redhat.com> (raw)
In-Reply-To: <20190625050008.12789-5-ehabkost@redhat.com>

On Tue, Jun 25, 2019 at 02:00:06AM -0300, Eduardo Habkost wrote:
> Base code for versioned CPU models.  This will register a "-4.1"
> version of all existing CPU models, and make the unversioned CPU
> models be an alias for the -4.1 versions on the pc-*-4.1 machine
> types.
> 
> On older machine types, the unversioned CPU models will keep the
> old behavior.  This way, management software can use old machine
> types while resolving aliases if compatibility with older QEMU
> versions is required.
> 
> Using "-machine none", the unversioned CPU models will be aliases
> to the latest CPU model version.
> 
> Includes a test case to ensure that:
> old machine types won't report any alias to versioned CPU models;
> "pc-*-4.1" will return aliases to -4.1 CPU models;
> and "-machine none" will report aliases to some versioned CPU model.

I'm wondering about the of tieing CPU versions to the release version
number and whether its a good idea or not ?

Could there be a reason for us to introduce 2 or more variants
of a CPU in the same release & would that be a problem if we needed
todo it ?

Consider if we did not have a Broadwell CPU model defined yet
and we were adding it at the same time as Spectre came out. We
might have needed to add "Broadwell-NN" and "Broadwell-MM" one
with "spec-ctrl" and one without, in order to ensure runability
on hosts with & without the microcode upgrade.  "Broadwell" alias
would resolve to either the NN or MM variant according to what
the current host supported.

One way to cope with that would have been to add a 3rd digit
after the version number. eg a Broadwell-4.1.1 and Broadwell-4.1.2

An alternative could consider using a plain counter for the CPU
versions eg Broadwell-1, Broadwell-2, etc.... ?

If we want to backport the newly added CPU model variants to
exist branches, plain counters don't have the unsightly mismatch.
eg we'd backport Broadwell-3 to QEMU 3.1, not Broadwell-4.1 to
QEMU 3.1.  This isn't a functional problem, just something looking
a bit odd.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|